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Abstract. There are many case studies for which the formulation of 
RDF constraints and the validation of RDF data conforming to these 
constraint is very important. As a part of the collaboration with the W3G 
and the DGMI working groups on RDF validation, we identified major 
RDF validation requirements and initiated an RDF validation require¬ 
ments database which is available to contribute at http://purl.org/net/rdf-validation 
The purpose of this database is to collaboratively collect case studies, use 
cases, requirements, and solutions regarding RDF validation. Although, 
there are multiple constraint languages which can be used to formulate 
RDF constraints (associated with these requirements), there is no stan¬ 
dard way to formulate them. This paper serves to evaluate to which ex¬ 
tend each requirement is satisfied by each of these constraint languages. 

We take reasoning into account as an important pre-validation step and 
therefore map constraints to DL in order to show that each constraint 
can be mapped to an ontology describing RDF constraints generically. 

Keywords: RDF Validation, RDF Validation Requirements, RDF Gon- 
straints, Gonstraint Languages, Evaluation, Linked Data, Semantic Web 


1 Introduction 

The W3C organized the RDF Validation Worksho]:0, where experts from in¬ 
dustry, government, and academia discussed first use cases for RDF constraint 
formulation and validation. In 2014, two working groups on RDF validation 
have been established: the W3C RDF Data Shaped and the DCMI RDF Ap¬ 
plication Profiles working group^. Bosch and Eckert [T] collected the findings 
of these working groups and initiated a database of requirements to formulate 
and validate RDF constraints. The database is available for contribution at 
http://purl.org/net/rdf-validation. The intention associated with this database 

http://www.w3.org/2012/12/rdf-val/ 

® http://www.w3.org/2014/rds/charter 

® http://wiki.dublmcore.org/index.php/RDF-Application-Profiles 



is to collaboratively collect case studies, use cases, requirements, and solutions 
regarding RDF validation in a comprehensive and structured way. The require¬ 
ments are classified to better evaluate existing solutions. We mapped each re¬ 
quirement to formulate RDF constraints directly to an RDF constraint type. 

A constraint lauiguage is a language which is used to formulate constraints. 
The W3C Data Shapes working group defines constraint as a component of 
a schema what needs to be satisfieqj- There is no constraint language which 
can be seen as the standalone standard. However, there are multiple constraint 
languages (each having its own syntax and semantics) which can be used to 
express RDF constraints, such as existential and universal quantification, car¬ 
dinality restrictions, and exclusive-or of properties. The five most popular con¬ 
straint languages are Descmtion Set Profiles (DSP jl. Resource Shapes (ReShj^, 
Shape Expressions fShEx'PH. the SPARQL Inferencing Notation (SPIN)0, and 
the Web Ontology Language (OWL 2)[3- 

In this paper, we describe each requirement within the RDF validation re¬ 
quirements database in detail (sections 2-75). Additional descriptions can be 
found directly in the database. Each requirement corresponds to an RDE con¬ 
straint type which may be expressible by multiple constraint languages. Eor each 
requirement, we represent some examples in different constraint languages. 

We evaluated to which extend the most promising five constraint languages 
fulfill each of the overall 74 requirements to formulate RDE constraints (sec¬ 
tion |82T]). We distinguished if a constraint is fulfilled by OWL 2 QL or if the 
more expressive OWL 2 DL is needed. We also take reasoning into account, as 
reasoning may be performed prior to validating constraints. 

In order to define an ontology to describe RDE constraints generically, it is 
needed to define the terminology for the formulation of RDE constraints and to 
classify them. We identified four dimensions to classify constraints: 

— Universality: specific constraints vs. generic constraints 

— Complexity: simple constraints vs. complex constraints 

— Context: property constraints vs. class constraints 

— DL Expressivity: constraints expressible in DL vs. constraints not express¬ 
ible in DL 

As there are already five promising constraint languages, our purpose is not 
to invent a new constraint language. We rather developed a very simple on¬ 
tology (only three classes, three object properties, and three data properties) 
which is universal enough to describe any RDE constraint expressible by any 
RDF constraint language. We call this ontology the RDF constraints ontology 
(RDF-CD)[il. 

^ https://www.w3.org/2014/data-shapes/wiki/Glossary 
® http://dublincore.org/documents/2008/03/31/dc-dsp/ 

® http://www.w3.org/Submission/shapes/ 
http://www.w3.org/Submission/shex-primer/ 
http://spinrdf.org/ 

http://www.w3.org/TR/owl2-syntax/ 

Available at: https://github.eom/boschthomas/RDF-CO 





Specific constraints are expressed by specific constraint languages like 
DSP, OWL 2, ReSh, ShEx, and SPIN. Generic constraints are expressed by 
the RDF-CO. As RDF-CO describes constraints generically, it does not distin¬ 
guish constraints according to the dimension universality. The majority of 
constraints can be expressed in DL. In contrast, there are constraints which 
cannot be expressed in DL, but are also expressible in the RDF-CO. Complex 
constraints are built by combining simple constraints or complex con¬ 
straints. DL statements which represents complex constraints are created out 
of DL statements representing composed constraints (if expressible in DL). Sim¬ 
ple constraints may be applied to either properties (properties constraints) 
or classes (class constraints). There are no terms representing simple and 
complex constraints in the RDF-CO, since context classes (associated simple 
constraints hold for individuals of these classes) of simple constraints may just 
be reused by further constraints. As a consequence, the distinction of property 
and class constraints is sufficient to describe all possible RDF constraints. 

In this paper, we investigate which constraints can be expressed in DL and 
which not. If a constraint can be expressed in DL, we added the mapping to DL 
and to the generic constraint in order to logically underpin associated require¬ 
ments. If a constraint cannot be expressed in DL, we only added the mapping to 
the generic constraint. Therefore, we show that each constraint can be mapped 
to a generic constraint. In section 182.21 we classify the constraints according to 
the dimensions to classify constraints. 

2 Subsumption 

Subsumption (DL terminology: concept inclusion) corresponds to the require¬ 
ment R-IOO-SUBSUMPTION. A subclass axiom SubClassOf( CEl CE2 ) states 
that the class expression CEl is a subclass of the class expression CE2. Roughly 
speaking, this states that CEl is more specific than CE2. 

2.1 Simple Example 

All mothers are parents. The concept Mother is subsumed by the concept Parent: 

Mother E Parent 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Mother 

- 

- 

Parent 




2.2 Simple Example 

Jedis feel the force: 


Jedi E FeelingForce 













Expressed by multiple constraint languages: 


# 0WL2: 

Jedi rdfs:subClassDf FeelingForce . 


# ReSh: 

the extension ext:extendsShape may be used 


# ShEx: 

FeelingForce { 

feelingForce (true) } 
Jedi { 

& FeelingForce , 
attitute (’good’) }■ 


Data matching the shapes FeelingForce and Jedi: 


Yoda 

feelingForce true ; 
attitute ’good’ . 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Jedi 

- 

- 

FeelingForce 




2.3 Complex Example 

If an individual is rich, then this individual is not poor: 


Rich E —' Poor 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

^ Poor 

- 

- 

Poor 



class 

Rich 

- 

- 

^ Poor 




3 Class Equivalence 

Class Equivalence corresponds to the requirement R-3-EQU1VALENT-CLASSES. 
Concept equivalence asserts that two concepts have the same instances [4]. While 
synonyms are an obvious example of equivalent concepts, in practice one more 
often uses concept equivalence to give a name to complex expressions [1] . Concept 
equivalence is indeed subsumption from left and right (A ^ B and B ^ A implies 
A = B). 
























3.1 Simple Example 


Person = Human 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Person 

- 

- 

Human 



class 

Human 

- 

- 

Person 




4 Sub Properties 

Sub Properties (DL terminology: role inclusion) correspond to the require¬ 
ments R-54-SUB-DBJECT-PR0PERTIES and R-54-SUB-DATA-PR0PERTIES. Sub¬ 
property axioms are analogous to subclass axioms. These axioms state that the 
property expression PEI is a subproperty of the property expression PE2 — 
that is, if an individual x is connected by PEI to an individual or a literal y, 
then X is also connected by PE2 to y. 


4.1 Simple Example 


parentOf E ancestorOf 

States that parentOf is a sub-role of ancestorOf , i.e., every pair of indi¬ 
viduals related by parentOf is also related by ancestorOf. 

Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

parentOf 

ancestorOf 

T 




4.2 Simple Example 


hasDog E hasPet 


4.3 Complex Example 

Person n 'ihasAge. Person n 'ihasEvenAge. ^lo 

5 Object Property Paths 

Object Property Paths (or Object Property Chains and in DL terminology 
complex role inclusion axiom or role composition) corresponds to the requirement 
R-55-0BJECT-PR0PERTY-PATHS. The more complex form of sub properties. This 
axiom states that, if an individual x is connected by a sequence of object property 
expressions OPEl, ..., OPEn with an individual y, then x is also connected with 
y by the object property expression OPE. Role composition can only appear on 
the left-hand side of complex role inclusions [4]. 




















5.1 Simple Example 

brotherOf o parentOf E uncleOf 

# 0WL2: 

uncleOf owlrpropertyChainAxiom ( brotherOf parentOf ) . 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

brotherOf, parentOf 

uncleOf 

T 


- 


6 Disjoint Properties 

Disjoint Properties corresponds to the requirement R-9-DISJ0INT-PR0PERTIES. 
A disjoint properties axiom states that all of the properties are pairwise disjoint; 
that is, no individual x can be connected to an individual y by these properties. 


6.1 Simple Example 

The object properties parentOf and childOf are disjoint: 

Disjoint (parentOf, childOf) 

or alternatively: 


parentOf E -^childOf 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

parentOf 

—■childOf 

T 




syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

parentOf 

childOf 

T 




7 Intersection 

Intersection (composition, conjunction) corresponds to the requirements 
R-15-C0NJUNCTI0N-0F-CLASS-EXPRESSI0NS and R-16-C0NJUNCTI0N-0F-DATA- 
RANGES. DLs allow new concepts and roles to be built using a variety of differ¬ 
ent constructors. We distinguish concept and role constructors depending on 
whether concept or role expressions are constructed. In the case of concepts, 
one can further separate basic Boolean constructors, role restrictions and nom- 
inals/enumerations [4]. Boolean concept constructors provide basic boolean op¬ 
erations that are closely related to the familiar operations of intersection, union 
and complement of sets, or to conjunction, disjunction and negation of logical 
expressions [4]. 






























Mother = Female n Parent 


Concept inclusions allow us to state that all mothers are female and that all 
mothers are parents, but what we really mean is that mothers are exactly the 
female parents. DLs support such statements by allowing us to form complex 
concepts such as the intersection (also called conjunction) which denotes the set 
of individuals that are both female and parents. A complex concept can be used 
in axioms in exactly the same way as an atomic concept, e.g., in the equivalence 
Mother = Female n Parent . 


7.1 Simple Example 


Female n Parent 

Complex concept of all individuals which are of the concept Female and of 
the concept Parent. 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Female n Parent 

- 

- 

Female, Parent 

n 



7.2 Simple Example 


Mother Female n Parent 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Mother 

- 

- 

Female, Parent 

n 



8 Disjunction 

Disjunction of classes or data ranges corresponds to the requirements 
R-17-DISJUNCTI0N-0F-CLASS-EXPRESSI0NS and R-18-DISJUNCTIDN-0F- 
DATA-RANGES. Synonyms are union and inclusive or. 


8.1 Simple Example 


Father u Mother u Child 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Father u Mother u Child 

- 

- 

Father, Mother, Child 

u 

















8.2 Simple Example 


Parent = Father u Mother 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Parent 

- 

- 

Father, Mother 

u 



9 Negation 


Negation (complement) corresponds to the requirements R-19-NEGATI0N-0F- 
CLASS-EXPRESSIONS and R-20-NEGATI0N-0F-DATA-RANGES. 

9.1 Simple Example 


-^Married 


Set of all individuals that are not married. 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

—' Married 

- 

- 

Married 




9.2 Complex Example 


Female n -■ Married 

All female individuals that are not married. 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

—' Married 

- 

- 

Married 



class 

Female n —> Married 

- 

- 

Female, —■ Married 

n 



10 Disjoint Classes 


Disjoint Classes corresponds to the requirement R-7-DISJOINT-CLASSES. A 
disjoint classes axiom states that all of the classes are pairwise disjoint; that is, 
no individual can be at the same time an instance of these classes. 
















10.1 Simple Example 

Individuals cannot be male and female at the same time: 

Male n Female E -L 


or alternatively: 


Male E -^Female 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Male n Female 

- 

- 

Male, Female 

n 


class 

T 

- 

- 

Male n Female, J_ 




syntactic sugar: 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 


c. element 

c. value 

class 

Male 

_ 

- 

Female 



class 

Female 

- 

- 

Male 

7^ 



10.2 Simple Example 

One can either be a hologram or a human, but not both: 

Hologram n Human E -L 


or alternatively: 


Flologram E -^Human 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Hologram n Human 

- 

- 

Hologram, Human 

n 


class 

T 

- 

- 

Hologram n Human, _L 




syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Hologram 

- 

- 

Human 

7^ 


class 

Human 

- 

- 

Hologram 












































11 Existential Quantifications 


Existential Quantification on Properties conforms to the requirement 
R-86-EXISTENTIAL-QUANTIFICATIDN-0N-PR0PERTIES. In DL terminology the 
existential quantification is also called existential restriction. An 
existential class expression consists of a property expression and a class expres¬ 
sion or a data range, and it contains all those individuals that are connected by 
the property expression to an individual that is an instance of the class expres¬ 
sion or to literals that are in the data range. 


11.1 Simple Example 


3 parentOf . T 

Complex concept that describes the set of individuals that are parents of at 
least one individual (instance of T). 

Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

3 parentOf . T 

parentOf 

- 

T 

3 



11.2 Simple Example 


3 parentOf . Female 

The complex concept describes those individuals that are parents of at least 
one female individual, i.e., those that have a daughter. 

Mapping to RDF-CO; 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

3 parentOf . Female 

parentOf 

- 

Female 

3 



11.3 Simple Example 


Parent = 3 parentOf . T 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

Parent 

parentOf 

- 

T 

3 



11.4 Simple Example 

ParentOfSon = 3 parentOf . Male 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

ParentOfSon 

parentOf 

- 

Male 

3 




12 Universal Quantifications 


Universal Quantification on Properties corresponds to the requirement 
R-91-UNIVERSAL-QUANTIFICATI0N-0N-PRDPERTIES, which is also called value 
restriction in DL terminology. 


{^R.Cf = {a G I (a, &) e & e C^} where is an interpretation function, 

is the domain, a, 6 G are individuals C is a concept, i? is a role. 


12.1 Simple Example 


V parentOf.Female 


The set of individuals all of whose children are female also includes those 
that have no children at all. 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

V parentOf . Female 

parentOf 

- 

Female 

V 



13 Property Domains 

Property Domain corresponds to the requirements R-25-DBJECT-PRDPERTY-D0MA1N 
and R-26-DATA-PR0PERTY-DDMA1N. The constraint restricts the domain of ob¬ 
ject and data properties. In DL terminology this constraint is also called domain 
restrictions on roles. The purpose is to declare that a given property is asso¬ 
ciated with a class, e.g. to populate input forms with appropriate widgets but 
also constraint checking. In 00 terms this is the declaration of a member, field, 
attribute or association. 3i?.T E C is the object property restriction where R is 
the object property (role) whose domain is restricted to concept C. 


13.1 Simple Example 


3 sonOf . T E Male 


Restricts the domain of sonOf to male individual, 
syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

sonOf 

- 

Male 

domain 




14 Property Ranges 


Property Range corresponds to the requirements R-28-DBJECT-PRDPERTY-RANGE 
and R-35-DATA-PRDPERTY-RANGE. This constraint restricts the range of object 
and data properties In DL terminology it is also called range restrictions on 
roles. T E ^R.C is the range restriction to the object property R (restricted by 
the concept C). 


14.1 Simple Example 

T E V sonOf . Parent 


equivalent to: 


IscmOf .T E Person 
Restricts the range of sonOf to parents. 


# OWL 2 : 

sonOf rdfstrainge Parent 


# DSP: 

:hasDogRange 

a dsp:DescriptionTemplate ; 
dsp:resourceClass owl:Thing ; 
dsp:statementTemplate [ 

a dsp:NonLiteralStatementTemplate ; 
dsp:property sonOf ; 
dsp:nonLiteralConstraint [ 

a dsp:NonLiteralConstraint ; 
dsp:valueClass Parent ] ] . 


syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

sonOf 

- 

Parent 

range 



15 Class-Specific Property Range 

Class-Specific Property Range corresponds to the requirements R-29-CLASS- 
SPECIFIC-RANGE-OF-RDF-OBJECTS and R-36-CLASS-SPECIFIC-RANGE-0F-RDF- 
LITERALS. The constraint restricts the range of object and data properties for 
individuals within a specific context (e.g. class, application profile). The values 
of each member property of a class may be limited by their value type, such as 
xsd:string or Person. 


15.1 Simple Example 

Only men can have sonOf relationships to parents: 

^Man E ^3 sonOf.Parent 




15.2 Simple Example 

Only vulcans can have friendship relationships to cardassians 
^Vulcan E ^3 friendOf.Carsassian 


16 Minimum Unqualified Cardinality Restrictions 

Minimum Unqualified Cardinality Restrictions on Properties corresponds 
to the requirements R-Sl-MINIMUM-UNQUALIFIED-CARDINALITY-DN-PRDPERTIES 
and R-211-CARDINALITY-C0NSTRAINTS. ni?.T is the minimum unqualified 
cardinality restriction where n e N (written ^ nR in short). A minimum cardi¬ 
nality restrictions contains all those individuals that are connected by a property 
to at least n different individuals/literals that are instances of a particular class 
or data range. If the class is missing, it is taken to be owhThing. If the data range 
is missing, it is taken to be rdfs:Literal. For unqualified cardinality restrictions, 
classes respective data ranges are not stated. 


16.1 Simple Example 


1 

# ShEx: 

2 

:Jedi { 

3 

rattitude (’good’) } 

4 

rJediStudent { 

5 

& :Jedi , 

6 

rstudentOf ■C}-Cl3- } 

7 

rJediMaster { 

8 

& :Jedi , 

9 

:)iientor0f } 

10 

:SuperJediMaster { 

11 

& :Jedi , 

12 

imentorOf {}-C3,} }■ 


— Jedis have the attitude ’good’ 

— Jedi students are students of exactly 1 resource 

— Jedi masters are mentoring at least 1 and at most 2 resources 

— Super Jedi masters are mentoring at least 3 resources 

1 

# data: 

2 

:Yoda 

3 

rattitude ’good’ ; 

4 

:mentorOf :MaceWindu , :0bi-Wcin , :Luke . 

5 

rMaceWindu 

6 

rattitude ’good’ ; 

7 

rstudentOf rYoda . 

8 

:Obi-Wan 

9 

rattitude ’good’ ; 

10 

rstudentOf rYoda ; 

11 

rmentorOf rAnakin . 

12 

:Anakin 

13 

rattitude ’good’ ; 

14 

rstudentOf :Obi-Wan . 

15 

: Luke 

16 

rattitude ’good’ ; 

17 

rstudentOf rYoda . 






# Individuals matching the SuperJediMaster’ data shape: 
:Yoda 


Jedi E 3attitude.{good} 
JediStudent E Jedin ^ IstudentOf .T n ^ IstudentOf.T 
JediMasters E Jedin > ImentorOf.Tn ^ 2mentorOf.T 
Super Jedi Master n Jedin ^ imentorOf.T 


16.2 Simple Example 

Captain IcommandsVessel.T 
Captains command at least one vessel. 

Mapping to RDF-CO; 



context class 

left p. list 

right p. list 


c. element 

c. value 

property 

Captain 

comma ndsVessel 

- 



1 


17 Minimum Qualified Cardinality Restrictions 

Minimum Qualified Cardinality Restrictions on Properties corresponds 
to the requirements R-75-MINIMUM-QUALIFIED-CARDINALITY-0N-PR0PERTIES 
and R-211-CARDINALITY-C0NSTRAINTS A minimum cardinality restrictions con¬ 
tains all those individuals that are connected by a property to at least n different 
individuals/literals that are instances of a particular class or data range. If the 
class is missing, it is taken to be owhThing. If the data range is missing, it is 
taken to be rdfs:Literal. For qualified cardinality restrictions, classes respective 
data ranges are stated. > nR.C is a minimum qualified cardinality restriction 
where n G N. 


17.1 Simple Example 


> 2 childOf . Parent 

Set of individuals that are children of at least two parents. 


# OWL 2: 
owl:Thing 

a owl:Restriction ; 

owliminQualifiedCardinality "2"“'‘xsdrnonNegativeInteger ; 
owl:onProperty childOf ; 
owl:onClass Parent . 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

^ 2 childOf . Parent 

childOf 

- 

Parent 


2 













17.2 Simple Example 

foaf:Person = > 2 hasName.xsd:string 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

foaf: Person 

hasName 

- 

xsdrstring 


2 


17.3 Simple Example 


1 # ShEx: 

2 rJedi { 

3 rattitude (’good’) } 

4 :JGdiStudent { 

5 & rJedi , 

6 :studGntOf QrJedi-Cl} } 

7 :JGdiMastGr { 

8 & rJedi , 

9 rmentorOf @:Jedi-Cl,23- )■ 

10 : SuperJediMaster ■( 

11 & rJedi , 

12 rmentorOf @rJedi-C3,} } 


— Jedis have the attitude ’good’ 

— Jedi students are students of exactly 1 Jedi 
— Jedi masters are mentoring at least 1 and at most 2 Jedis 
— Super Jedi masters are mentoring at least 3 Jedis 

1 
2 

3 

4 

5 

6 

7 

8 
9 

10 
11 
12 

13 

14 

15 

16 
17 


1 

2 

3 

4 

5 


# datar 
rYoda 

rattitude ’good’ ; 

rmentorOf rMaceWindu , rObi-Wain , rLuke 
rMaceWindu 

rattitude ’good’ ; 
rstudentOf rYoda . 
r Obi-Wan 

rattitude ’good’ ; 
rstudentOf rYoda ; 
rmentorOf rAnakin . 
r Anakin 

rattitude ’good’ ; 
rstudentOf rObi-Wan . 
r Luke 

rattitude ’good’ ; 
rstudentOf rYoda . 


# Individuals matching the ’rSuperJediMaster’ data shaper 
rYoda 

# Individuals matching the ’rJediMaster’ data shaper 
r Obi-Wan 


mentorOf and studentOf are taken to be inverse properties: 


Jedi E 3attitude.{good} 
JediStudent E Jedin ^ IstudentOf.Jedin ^ IstudentOf.Jedi 
JediMasters E Jedin ^ ImentorOf.Jedin ^ 2mentorOf.Jedi 
Super JediMaster E Jedin > imentorO f .J edi 























17.4 Complex Example 


Fatlier2Daughters = Man n (> 2 hasChild.Woman) 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

^ 2 hasChild.Woman 

hasChild 

- 

Woman 


2 

class 

Father2Daughters 

- 

- 

Man, ^ 2 hasChild.Woman 

n 

- 


17.5 Simple Example 


Captain IcommandsVessel.Vessel 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 


c. element 

c. value 

property 

Captain 

comma ndsVessel 

- 

^^1 


1 


17.6 Complex Example 


FederationCaptain E Federations ^ IcommandsVessel.Vessel 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

commandsVessel . Vessel 

commandsVessel 

- 

Vessel 


1 

class 

FederationCaptain 

- 

- 

Federation, ^1 commandsVessel . Vessel 

n 

- 


18 Mciximum Unqualified Cardinality Restrictions 

Maximum Unqualified Cardinality Restrictions on Properties corresponds 
to the requirements R-82-MAXIMUM-UNqUALIFIED-CARDINALITY-DN-PRDPERTIES 
and R-211-CARDINALITY-CONSTRAINTS. A maximum cardinality restriction con¬ 
tains all those individuals that are connected by a property to at most n different 
individuals/literals that are instances of a particular class or data range. If the 
class is missing, it is taken to be owhThing. If the data range is not present, it 
is taken to be rdfs:Literal. Unqualified means that the class respective the data 
range is not stated. ^ nR.T is a maximum unqualified cardinality restriction 
where n G N (written > nR in short). 



































18.1 Simple Example 


1 

# ShEx: 

2 

:Jedi { 

3 

rattitude (’good’) } 

4 

:JediStudent { 

5 

& :Jedi , 

6 

:studentQf ■C}-Cl3- } 

7 

rJediMaster { 

8 

& :Jedi , 

9 

rmentorOf } 

10 

:SuperJediMaster { 

11 

& :Jedi , 

12 

rmentorOf {}-C3,} }■ 


— Jedis have the attitude ’good’ 

— Jedi students are students of exactly 1 resource 

— Jedi masters are mentoring at least 1 and at most 2 resources 

— Super Jedi masters are mentoring at least 3 resources 

1 

# data: 

2 

:Yoda 

3 

rattitude ’good’ ; 

4 

rmentorOf rMaceWindu , rObi-Wain , rLuke . 

5 

rMaceWindu 

6 

rattitude ’good’ ; 

7 

rstudentOf rYoda . 

8 

:Obi-Wan 

9 

rattitude ’good’ ; 

10 

rstudentOf rYoda ; 

11 

rmentorOf rAnakin . 

12 

:Anakin 

13 

rattitude ’good’ ; 

14 

rstudentOf :Obi-Wan . 

15 

: Luke 

16 

rattitude ’good’ ; 

17 

rstudentOf rYoda . 


# Individuals matching the • 

’rJediMaster’ data shape: 

:Obi-Wan 



Jedi E 3attitude.{good} 
JediStudent E Jedin > IstudentOf .T n ^ IstudentOf.T 
JediMasters E Jedin > ImentorOf.Tn ^ 2mentorOf.T 
Super Jedi Master E Jedin ^ ImentorOf .T 


19 Maximum Qualified Cardinality Restrictions 

Maximum Qualified Cardinality Restrictions on Properties corresponds 
to the requirements R-76-MAXIMUM-QUALIFIED-CARDINALITY-0N-PR0PERTIES 
and R-211-CARDINALITY-CONSTRAINTS. A maximum cardinality restriction con¬ 
tains all those individuals that are connected by a property to at most n different 
individuals/literals that are instances of a particular class or data range. If the 
class is missing, it is taken to be owl:Thing. If the data range is not present, it is 
taken to be rdfsiLiteral. Qualified means that the class respective the data range 
is stated. ^ nR.C is a maximum qualified cardinality restriction where n G N. 











19.1 Simple Example 


^ 2 childOf . Parent 

Set of individuals that are children of at most two parents. 

Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 


c. element 

c. value 

property 

^ 2 childOf . Parent 

childOf 




2 


19.2 Simple Example 


1 # ShEx: 

2 :Jedi { 

3 rattitude (’good’) } 

4 rJediStudent { 

5 & :Jedi , 

6 rstudentOf QiJedi-Cl)- } 

7 rJediMaster { 

8 & :Jedi , 

9 rmentorOf @:Jedi-Cl,23- )■ 

10 :SuperJediMaster { 

11 & :Jedi , 

12 :mentor0f @:JGdi-C3,} } 


— Jedis have the attitude ’good’ 

— Jedi students are students of exactly 1 Jedi 

— Jedi masters are mentoring at least 1 and at most 2 Jedis 

— Super Jedi masters are mentoring at least 3 Jedis 


1 

# data: 

2 

:Yoda 

3 

rattitude ’good’ ; 

4 

:mentorOf :MaceWindu , rObi-Wcin , :Luke . 

5 

rMaceWindu 

6 

:attitude ’good’ ; 

7 

rstudentOf rYoda . 

8 

:Obi-Wan 

9 

rattitude ’good’ ; 

10 

rstudentOf rYoda ; 

11 

rmentorOf rAnakin . 

12 

:Anakin 

13 

rattitude ’good’ ; 

14 

rstudentOf :Obi-Wan . 

15 

: Luke 

16 

rattitude ’good’ ; 

17 

rstudentOf rYoda . 


# Individuals matching the • 

’rJediMaster’ data shape: 

:Obi-Wan 



Jedi E 3attitude.{good} 
JediStudent E Jedin ^ IstudentOf.Jedin ^ IstudentOf.Jedi 
JediMasters c Jedin ^ ImentorOf.Jedin ^ 2mentorOf.Jedi 
Super JediMaster E Jedin > imentorO f .J edi 




















20 Exact Unqualified Cardinality Restrictions 

Exact Unqualified Cardinality Restrictions on Properties corresponds 
to the requirements R-80-EXACT-UNQUAL1F1ED-CARD1NAL1TY-0N-PR0PERT1ES 
and R-211-CARD1NAL1TY-C0NSTRA1NTS. An exact cardinality restriction con¬ 
tains all those individuals that are connected by a property to exactly n different 
individuals that are instances of a particular class or data range. If the class is 
missing, it is taken to be owhThing. If the data range is not present, it is taken 
to be rdfs:Literal. Unqualified means that the class respective data range is not 
stated. > nR.T n ^ nR.T is an exact unqualified cardinality restriction where 
n e N. 


20.1 Simple Example 


1 # ShEx: 

2 rJediStudent { 

3 rstudentOf ■C}-Cl} } 


1 # ReSh: 

2 rJediStudent a rs:ResourceShape ; 

3 rs:property [ 

4 rsrname "studentOf" ; 

5 rsrpropertyDefinition rstudentOf ; 

6 rs:valueShape [ a rs:ResourceShape] ; 

7 rs:occurs rs:Exactly-one ; ] . 


— Jedis have the attitude ’good’ 

— Jedi students are students of exactly 1 resource 


1 

# data: 

2 

:Yoda 

3 

rattitude ’good’ ; 

4 

rmentorOf rMaceWindu , rObi-Wain , :Luke . 

5 

rMaceWindu 

6 

rattitude ’good’ ; 

7 

rstudentOf rYoda . 

8 

:Obi-Wan 

9 

rattitude ’good’ ; 

10 

rstudentOf rYoda ; 

11 

rmentorOf rAnakin . 

12 

:Anakin 

13 

rattitude ’good’ ; 

14 

rstudentOf :Obi-Wan . 

15 

: Luke 

16 

rattitude ’good’ ; 

17 

rstudentOf rYoda . 


1 # Individuals matching the ’rJediStudent’ data shape: 

2 rMaceWindu :Obi-Wan rAnakin rLuke 


JediStudent E Jedin ^ IstudentOf.T n ^ IstudentOf.T 














21 Exact Qualified Cardinality Restrictions 

Exact Qualified Cardinality Restrictions on Properties corresponds to 
the requirements R-74-EXACT-QUAL1F1ED-CARD1NAL1TY-DN-PRDPERT1ES and 
R-211-CARD1NAL1TY-C0NSTRA1NTS. An exact cardinality restriction contains all 
those individuals that are connected by a property to exactly n different in¬ 
dividuals that are instances of a particular class or data range. If the class is 
missing, it is taken to be owhThing. If the data range is not present, it is taken 
to be rdfs:Literal. Qualified means that the class respective data range is stated. 
> nR.Cr\ ^ nR.C is an exact qualified cardinality restriction where n G N. 


21.1 Simple Example 


1 

2 

3 

4 

5 

6 
7 


10 

11 

12 

13 

14 

15 


# ShEx: 

:Jedi { 

rattitude (’good’) } 
rJediStudent { 

rstudentOf (9:Jedi{l3- } 


# ReSh: 

:JGdi a rs:ResourceShape ; 
rs:property [ 

rsiname "attitude" ; 
rs:propertyDefinition rattitude ; 
rs:allowedValue "good" ; 
rs:occurs rs:Exactly-one ; 

] . 

rJediStudent a rs:ResourceShape ; 
rs:property [ 

rsrname "studentOf" ; 
rsrpropertyDefinition rstudentOf ; 
rs:valueShape rJedi ; 
rs:occurs rs:Exactly-one ; 

] . 


— Jedis have the attitude ’good’ 

— Jedi students are students of exactly 1 Jedi 


1 

# data: 

2 

:Yoda 

3 

rattitude ’good’ ; 

4 

rmentorOf rMaceWindu , rObi-Wein , rLuke . 

5 

rMaceWindu 

6 

rattitude ’good’ ; 

7 

rstudentOf rYoda . 

8 

:Obi-Wan 

9 

rattitude ’good’ ; 

10 

rstudentOf rYoda ; 

11 

rmentorOf rAnakin . 

12 

:Anakin 

13 

rattitude ’good’ ; 

14 

rstudentOf :Obi-Wan . 

15 

: Luke 

16 

rattitude ’good’ ; 

17 

rstudentOf rYoda . 


1 # Individuals matching the ’rJediStudent’ data shape: 

2 rMaceWindu :Obi-Wan rAnakin rLuke 












Jedi E lattitude.{good} 
JediStudent E Jedin > IstudentOf.Jedin ^ IstudentOf.Jedi 


21.2 Complex Example 

Person E > 2 childOf . Parent n ^ 2 childOf . Parent 
Every person is a child of exactly two parents. 

Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

^ 2 childOf . Parent 

childOf 

- 

Parent 


2 

property 

2 childOf . Parent 

childOf 

- 

Parent 


2 

class 

Person 

- 

- 

^ 2 childOf . Parent, 2 childOf . Parent 

n 

- 


syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

Person 

childOf 

- 

Parent 


2 


22 Inverse Object Properties 

Inverse Object Properties corresponds to the requirement R-56-INVERSE- 
OBJECT-PRDPERTIES. In many cases properties are used bi-directionally and then 
accessed in the inverse direction, e.g. parent = child“. There should be a way to 
declare value type, cardinality etc of those inverse relations without having to 
declare a new property URL The object property OPl is an inverse of the object 
property OP2. Thus, if an individual x is connected by OPl to an individual y, 
then y is also connected by OP2 to x, and vice versa. 


22.1 Simple Example 


parentOf = childOf 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

parentOf 

childOf 

- 

inverse 



22.2 Simple Example 


captainOf = hasCaptain 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

captainOf 

hasCaptain 

- 

inverse 















23 Transitive Object Properties 


Transitive Object Properties corresponds to the requirement 
R-63-TRANSITIVE-0BJECT-PRDPERTIES. Transitivity is a special form of com¬ 
plex role inclusion. An object property transitivity axiom states that the object 
property is transitive — that is, if an individual x is connected by the object 
property to an individual y that is connected by the object property to an indi¬ 
vidual z, then X is also connected by the object property to z. 

23.1 Simple Example 

ancestorOf o ancestorOf E ancestorOf 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

ancestorOf, ancestorOf 

ancestorOf 

- 




syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

ancestorOf 

- 

- 

transitive 



24 Symmetric Object Properties 

Symmetric Object Properties corresponds to the requirement 
R-61-SYMMETRIC-DBJECT-PRDPERTIES. A role is symmetric if it is equivalent to 
its own inverse [4]. An object property symmetry axiom states that the object 
property expression OPE is symmetric - that is, if an individual x is connected 
by OPE to an individual y, then y is also connected by OPE to x. 


24.1 Simple Example 

The property marriedTo is symmetric: 

marriedTo = marriedTo 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

marriedTo 

marriedTo 

- 

inverse 



syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

marriedTo 

- 

- 

symmetric 







































25 Asymmetric Object Properties 


Asymmetric Object Properties corresponds to the requirement 
R-62-ASYMMETRIC-0BJECT-PR0PERTIES. A role is asymmetric if it is disjoint 
from its own inverse [3]. An object property asymmetry axiom AsymmetricOb- 
jectProperty( OPE ) states that the object property expression OPE is asym¬ 
metric - that is, if an individual x is connected by OPE to an individual y, then 
y cannot be connected by OPE to x. 


25.1 Simple Example 

The property parentOf is asymmetric: 

parentOf E ^parentOf~ 

alternatively: 

parentOf n parentOf~ E T 

alternatively: 


disjoint (parentOf, parentOf ) 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

parentO f~ 

parentOf 

- 

inverse 


property 

T 

parentOf 

parentO f~ 

- 




syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

parentOf 

- 

- 

asymmetric 



25.2 Simple Example 

Child parent relations (dbo:child) cannot be symmetric. 

25.3 Simple Example 

Person birth place relations (dbo:birthPlace) cannot be symmetric. 

26 Class-Specific Reflexive Object Properties 

Using DL terminology Class-Specific Reflexive Object Properties is called 
local reflexivity - a set of individuals (of a specific class) that are related to them¬ 
selves via a given role [4]. 




















26.1 Simple Example 


TalkingToThemselves E 3 talksTo .Self. 
Set of individuals that are talking to themselves. 

Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

TalkingToThemselves 

talksTo 

- 

Self 

3 



syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

3 talksTo .Self 

talksTo 

- 

- 

reflexive 



27 Reflexive Object Properties 


Reflexive Object Properties (reflexive roles, global reflexivity in DL) cor¬ 
responds to the requirement R-59-REFLEXIVE-DBJECT-PR0PERTIES. Global re¬ 
flexivity can be expressed by imposing local reflexivity on the top concept [4]. 


27.1 Simple Example 

Each individual knows itself: 


T E 3 knows . Self 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

3 knows . Self 

knows 

- 

Self 

3 


class 

T 

- 

- 

T, 3 knows . Self 




syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

knows 

- 

- 

reflexive 



28 Irreflexive Object Properties 

Irreflexive Object Properties (irreflexive roles in DL) corresponds to the 
requirement R-60-IRREFLEXIVE-0BJECT-PR0PERTIES. A role is irreflexive if it is 
never locally reflexive [1]. An object property irreflexivity axiom IrreflexiveOb- 
jectProperty( OPE ) states that the object property expression OPE is irreflexive 
- that is, no individual is connected by OPE to itself. 






































28.1 Simple Example 


T E ^ 3marriedTo.Self 


alternatively: 


ImarriedTo.Self E -L 


alternatively: 


marriedTo n marriedTo E -L (without special self-concept Self) 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

3 marriedTo . Self 

knows 

- 

Self 

3 


class 

—' 3 marriedTo . Self 

- 

- 

3 marriedTo . Self 



class 

T 

- 

- 

T, —' 3 marriedTo . Self 




syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

marriedTo 

- 

- 

irrefiexive 



28.2 Simple Example 

A resource cannot be its own parent (dbo:parent). 


28.3 Simple Example 

A resource cannot be its own child (dbo:child). 


28.4 Class-Specific Irrefiexive Object Properties 

A property is irrefiexive if it is never locally reflexive [1]. An object property 
irreflexivity axiom states that the object property OP is irrefiexive - that is, no 
individual is connected by OP to itself. Class-Specific Irreflexive Object Prop¬ 
erties are object properties which are irrefiexive within a given context, e.g. a 
class. 




















28.5 Simple Example 

Persons cannot be married to themselves. 

Person E -■ ImarriedTo.Self 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

3 marriedTo . Self 

knows 

- 

Self 

3 


class 

—' 3 marriedTo . Self 

- 

- 

3 knows . Self 



class 

Person 

- 

- 

Person, —> 3 marriedTo . Self 




syntactic sugar: 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 


c. element 

c. value 

property 

Person 

marriedTo 

- 


irreflexive 



29 Context-Specific Property Groups 

Context-Specific Property Groups corresponds to the requirement 
R-66-PRDPERTY-GR0UPS to group data and object properties. 

29.1 Simple Example 


# ShEx: 

<Humcin> { 

( 

foaf:name xsd:string , 
foaf:givenName xsd:string 

) , 

( 

foaf:mbox IRI , 
foaf:homepage foaf:Document 

) > 


— 1. group: 1 foahname (range: xsd:string) and 1 foahgivenName (range: xsd:string) 
and (,) 

— 2. group: 1 foahmbox (range: IRI) and 1 foahhomepage (range: foahDocnment) 


Human = M n N 
M = C n F 

C E > 1 name . string n ^ 1 name . string 
F E > 1 givenName . string n ^ 1 givenName . string 

N = I n L 

I E ^ 1 mbox . string n ^ 1 mbox . string 
L E 1 homepage . Document n ^ 1 homepage . Document 




















Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Human 

- 

- 

M. N 

n 

- 

class 

M 

- 

- 

C, F 

n 

- 

class 

c 

- 

- 

A, B 

n 

- 

property 

A 

foaf:name 

- 

string 


1 

property 

B 

foaf:name 

- 

string 


1 

class 

F 

- 

- 

D, E 

n 

- 

property 

D 

foaf:givenName 

- 

string 


1 

property 

E 

toat:givenl\lame 

- 

string 


1 

class 

N 

- 

- 

l> L 

n 

- 

class 

1 

- 

- 

G, H 

n 

- 

property 


foaf:mbox 

- 

string 


1 

property 


foaf:mbox 

- 

string 


1 

class 


- 

- 

J, K 

n 

- 

property 


foaf:homepage 

- 

foaf:Document 


1 

property 

^_ 

foaf:homepage 

- 

foaf:Document 


1 


30 Context-Specific Exclusive OR of Properties 

Context-Specific Exclusive OR of Properties correponds to the require¬ 
ment R-ll-CONTEXT-SPECIFIC-EXCLUSIVE-OR-DF-PRDPERTIES. Exclusive or is 
a logical operation that outputs true whenever both inputs differ (one is true, 
the other is false). This constraint is generally expressed in DL as follows: 

C E n B) u (A n ^B) 

and alternatively: 

C ^ {A u B) n -^{A n B) 


30.1 Simple Example 


1 # ShEx: 

2 <Humaii> { ( 

3 foaf:name xsd:string I 

4 foaf:givenName xsd:string ) } 


1 # OWL 2: 

2 Humcin owl:disjointUnionOf ( :CC1 :CC2 ) . 

3 

4 CCl rdfs:subClassOf [ 

5 a owl:Restriction ; 

6 owl:onProperty foaf:name ; 

7 owl:someValuesFrom xsd:string ] . 

8 CC2 rdfs:subClassOf [ 

9 a owl:Restriction ; 

10 owl:onProperty foaf:givenName ; 

11 owl:someValuesFrom xsd:string ] . 


— 1 foahname (range xsd:string) XOR 1 foahgivenName (range xsd:string) 


Human E (-■ A n B) u (A n -■ B) 
A E ^ 1 name . string n ^ 1 name . string 
B E > 1 givenName . string n ^ 1 givenName . string 


















Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

|c. element 

|c. value 

class 

Human 

- 

- 

—'AnB, An—'B 



class 

A n - B 

- 

- 

A, - B 

n 


class 

- A n B 

- 

- 

- A, B 

n 


class 

- A 

- 

- 

A 



class 

A 

- 

- 

^ 1 name.string, 1 name.string 

n 

- 

property 

^ 1 name.string 

name 

- 

string 


1 

property 

^ 1 name.string 

name 

- 

string 


1 

class 

- B 

- 

- 

B 



class 

B 

- 

- 

^ 1 givenName.string, ^ 1 givenName.string 

n 

- 

property 

^ 1 givenName.string 

givenName 

- 

string 


1 

property 


givenName 

- 

string 


1 


syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

= 1 name.string 

name 

- 

string 


1 

property 

= 1 givenName.string 

givenName 

- 

string 


1 

class 

Human 

- 

- 

= 1 name.string, = 1 givenName.string 

XOR 



30.2 Simple Example 


1 # ShEx: 

2 <FeelingForce> { ( 

3 attackingBySword xsdrboolecin | 

4 attackingByForce xsdrboolecin ) } 


1 

2 

3 

4 

5 

6 
7 


10 


# OWL 2 DL: 

FeelingForce owlrdisjointUnionOf ( CCl CC2 ) . 

CCl rdfs:subClassOf [ 
a owl:Restriction ; 
owl:onProperty attackingBySword ; 
owl:someValuesFrom xsd:boolean ] . 

CC2 rdfs:subClassOf [ 
a owl:Restriction ; 
owl:onProperty attackingByForce ; 
owl:someValuesFrom xsd:boolean ] . 


This means that FeelingForce individuals are individuals having one 
attackingBySword relationship (range xsdiboolean) or one attackingByForce 
relationship (range xsd:boolean) but not both. 

A 3 attackingBySword.xsd:boolean 
B = 3 attackingByForce.xsd:boolean 
FeelingForce c (-. A n B) u (A n -■ B) 


30.3 Simple Example 


Person E {{Male n -^Female) u {-^Male n Female)) 











































30.4 Complex Example 


# ShEx: 

<Humcin> { ( 

foaf:name xsd:string I foaf:givenName xsd:string+ , 
foaf:familyName xsd:string ) }■ 


— 1 foafiname (range xsd:string) XOR 1-n foaf:givenName (range xsd:string) 

— and 

— 1 foafdamilyName (range xsd:string) 

Individuals matching the ’Hnman’ data shape: 


:Han 

foaf:namG "Han Solo" ; 
foaf:familyName "Solo" . 

:Anakin 

foaf:givenName "Anakin" ; 
foaf:givenName "Darth" ; 
foaf:familyName "Skywalker" . 


Individual not matching the ’Human’ data shape: 


:Anakin 

foaf:name "Anakin Skywalker" ; 
foaf:givenName "Anakin" ; 
foaf:familyName "Skywalker" . 


31 Context-Specific Inclusive OR of Properties 

Context-Specific Inclusive OR of Properties corresponds to the require¬ 
ment R-202-C0NTEXT-SPECIFIC-INCLUSIVE-DR-0F-PR0PERTIES. Inclusive or is 
a logical connective joining two or more predicates that yields the logical value 
’’true” when at least one of the predicates is true. The context can be a class, 
i.e., the constraint applies for individuals of this specific class. 

31.1 Simple Example 

— 1 foahname (range: xsd:string) OR 1 foahgivenName (range: xsd:string) 

— it is also possible that both 1 foahname and 1 foahgivenName are stated 

— context: class Human 


Human E A u B 
A E > 1 name . string n ^ 1 name . string 
B E > 1 givenName . string n ^ 1 givenName . string 


syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

= 1 name.string 

name 

- 

string 


1 

property 

= 1 givenName.string 

givenName 

- 

string 


1 

class 

Human 

- 

- 

= 1 name.string, = 1 givenName.string 

u 
























32 Context-Specific Exclusive OR of Property Groups 


Context-Specific Exclusive OR of Property Groups corresponds to the re¬ 
quirement; R-13-DISJ0INT-GR0UP-0F-PR0PERTIES-CLASS-SPECIFIC. Exclusive 
or is a logical operation that outputs true whenever both inputs differ (one is 
true, the other is false). Only one of multiple property groups leads to valid data. 

32.1 Simple Example 

# ShEx: 

<Humcin> { 

( 

foafiname xsd:string , 
foaf:givenName xsd:string ) 

I 

( 

foafimbox IRI , 

foaf: homepage foaf: Document ) }■ 


— 1. group XOR 2. group 

— 1. group: 1 foahname (range: xsd:string) and 1 foahgivenName (range: xsd:string) 

— 2. group: 1 foahmbox (range: IRI) and 1 foahhomepage (range: foahDocument) 

— context: class Human 


: //purl. org/net/thomasbosch]-> 


: //purl. org/net/thomasbosch}-> 


# valid data: 

I Thomas 

a Human ; 

foaf:mbox <thomas.boschOgesis.org> ; 

foaf:homepage <\protect\vrule widthOpt\protect\href{http://purl.org/net/thomasbosch}{htt| 


# invalid data: 

I Thomas 

a Human ; 

foaf:name ’Thomas Bosch’ ; 
foaf:givenName ’Thomas’ ; 
foaf:mbox <thomas.boschOgesis.org> ; 

foaf:homepage <\protect\vrule widthOpt\protect\href{http://purl.org/net/thomasbosch}{htt| 


Human E (-■ E n F) u (E n -■ F) 
E = A n B 
F C n D 

A E > 1 name . string n ^ 1 name . string 
B E > 1 givenName . string n ^ 1 givenName . string 
C E ^ 1 mbox . IRI n ^ 1 mbox . IRI 
D c ^ 1 homepage . Document n ^ 1 homepage . Document 


syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Human 

- 

- 

E, F 

XOR 


class 

E 

- 

- 

= 1 name.string, = 1 givenName.string 

n 


class 

F 

- 

- 

= 1 mbox.IRI, = 1 homepage.Document 

n 


property 

= 1 name.string 

name 

- 

string 

= 

1 

property 

= 1 givenName.string 

givenName 

- 

string 


1 

property 

— 1 mbox.IRI 

mbox 

- 

IRI 


1 

property 

= 1 homepage.Document 

homepage 

- 

Document 


1 





33 Context-Specific Inclusive OR of Property Groups 


At least one property group must match for individuals of a specific context. 
Context may be a class, a shape, or an application profile. 


33.1 Simple Example 

— 1. group OR 2. group 

— 1. group: 1 foafifirstName (range: xsd:string) and 1 foahlastName (range: 
xsd:string) 

— 2. group: 1 foahgivenName (range: xsd:string) and 1 foahfamilyName (range: 
xsd:string) 

— context: class Person 


# valid data: 

:Anakin 

a :Person ; 

foaf:firstName ’Anakin’ ; 
foaf:lastName ’Skywalker’ ; 
foaf:givenName ’Anakin’ ; 
foaf:familyName ’Skywalker’ . 


# invalid data: 
:Anakin 

a :Person . 


Human E E u F 
E = A n B 
F = C n D 

A E > 1 name . string n ^ 1 name . string 
B E > 1 givenName . string n ^ 1 givenName . string 
C E ^ 1 mbox . IRI n ^ 1 mbox . IRI 
D c ^ 1 homepage . Document n ^ 1 homepage . Document 

syntactic sugar: 

Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Human 

- 

- 

E, F 

u 


class 

E 

- 

- 

= 1 name.string, = 1 givenName.string 

n 


class 

F 

- 

- 

= 1 mbox.IRI, = 1 homepage.Document 

n 


property 

= 1 name.string 

name 

- 

string 

= 

1 

property 

= 1 givenName.string 

givenName 

- 

string 


1 

property 

— 1 mbox.IRI 

mbox 

- 

IRI 


1 

property 

= 1 homepage.Document 

homepage 

- 

Document 


1 


34 Allowed Values 

Allowed Values corresponds to the requirements: R-30-ALL0WED-VALUES-F0R- 
RDF-OBJECTS and R-37-ALLDWED-VALUES-F0R-RDF-LITERALS. It is a common 







requirement to narrow down the value space of a property by an exhaustive 
enumeration of the valid values (both literals or resource). This is often ren¬ 
dered in drop down boxes or radio buttons in user interfaces. Allowed values for 
properties 

— must be these IRIs, 

— must be IRIs matching specific patterns, 

— must be IRIs matching one of multiple patterns, 

— must be (any) literals, 

— must be literals of a list of allowed literals (e.g. ’’red” ’’blue” ’’green”), 

— must be typed literals of this type (e.g. XML dataType). 


34.1 Example 


# DSP: 

descriptionTemplate 

a dspiDescriptionTemplate ; 
dsp:minOccur "0"'‘~xsd:nonNegativeInteger ; 
dsp:maxOccur "infinity"'■'‘xsd:string ; 
dsp:resourceClass swrciBook ; 
dsp:statementTemplate [ 

a dsp:NonLiteralStatementTemplate ; 
dsp:minQccur "0"'‘''xsd:nonNegativeInteger ; 
dsprmaxQccur "infinity"'"'xsd:string ; 
dsp:property determs:subject ; 
dsp:nonLiteralConstraint [ 

a dsp:NonLiteralConstraint ; 
dsp:valueClass skos:Concept ; 

dsp:valueURI ComputerScience, SocialScience, Librarianship ] ] . 


# 0WL2: 

determs:subject rdfs:range ObjectOneOf . 

# EquivalentClasses( ObjectOneOf ObjectOneOfC ComputerScience SocialScience Librarieinship ) 
ObjectOneOf owl:equivalentClass [ 

a owl:Class ; 

owl:oneOf ( ComputerScience SocialScience Librarianship ) ] . 


The range of the object property determs: subject must consist of the indi¬ 
viduals ComputerScience SocialScience Librarianship which are of the class 
skos:Concept: 


T E V dctermsisubject . skosiConcept n 
( {ComputerScience} u {SocialScience} u {Librarianship} ) 


34.2 Simple Example 

Beatle = {John} u {paul} u {george} u {ringo} 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Beatle 

- 

- 

[john], {paul\, [george], [ringo] 

u 









34.3 Simple Example 


{ComputerScience} u {SocialScience} u {Librarianship} 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

1 classes 

c. element 

c. value 

class 

complex concept 

- 

- 


u 

- 


34.4 Simple Example 

Jedis have blue, green, or white laser swords. 


1 

2 

3 

4 

5 

6 
7 


10 

11 

12 


# DSP: 

personDescriptionTemplate 

a dspiDescriptionTemplate ; 
dsp:resourceClass Jedi ; 
dsp:statementTemplate [ 

a dsp:LiteralStatementTemplate ; 
dsp:property laserSwordColor ; 
dsp:literalConstraint [ 

a dsp:LiteralConstraint ; 
dsp:literal "blue" ; 
dsp:literal "green" ; 
dsp:literal "white"] ] . 


1 # 0WL2: 

2 laserSwordColor rdfs:range laserSwordColors . 

3 laserSwordColors 

4 a rdfs:Datatype . 

5 owl:oneOf ( "blue" "green" "white" ) . 


1 # ReSh: 

2 Jedi a rs:ResourceShape ; 

3 rs:property [ 

4 rs:name "laserSwordColor" ; 

5 rs:propertyDefinition laserSwordColor ; 

6 rs:allowedValue "blue" , "green" , "white" ; 

7 rs:occurs rs:Exactly-one ; ] . 


1 # ShEx: 

2 Jedi { 

3 laserSwordColor (’blue’ ’green’ ’white’) } 


1 # Jedi individuals: 

2 Yoda 

3 laserSwordColor ’blue’ . 


Jedi = 3 laserSwordColor.{blue, green, white} 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

Jedi 

laserSwordColor 

- 

LaserSwordColor 

3 

- 

class 

LaserSwordColor 

- 

- 

{blue}, {green}, {white} 

u 

- 








































35 Not Allowed Values 


Not Allowed Values corresponds to the requirements R-33-NEGAT1VE-0BJECT- 
CDNSTRAINTS and R-200-NEGAT1VE-L1TERAL-C0NSTRA1NTS. A matching triple 
has any literal / object except those explicitly excluded. 


35.1 Simple Example 

Siths do not have blue, green, or white laser swords. 


# 0WL2: 

laserSwordColor rdfs:range negativeLaserSwordColors . 
NegativeLaserSwordColors 
a rdfsrDatatype . 

owl:complementOf laserSwordColors . 
laserSwordColors 

a rdfs:Datatype . 

owl:oneOf ( "blue" "green" "white" ) . 


# ShEx: 

Sith -C 

! laserSwordColor (’blue’ ’green’ ’white’) }■ 


# Sith individuals: 
DarthSidious 

laserSwordColor ’red’ . 


Sith = ^ 3 laserSwordColor . {blue, green, white} 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

3 laserSwordColor . LaserSwordColor 

laserSwordColor 

- 

LaserSwordColor 

3 

- 

class 

Sith 

- 

- 

3 laserSwordColor . LaserSwordColor 


- 

class 

LaserSwordColor 

- 

- 

{blue}, {green}, {white} 

u 

- 


36 Membership in Controlled Vocabularies 

Membership in Controlled Vocabularies corresponds to the requirements 
R-32-MEMBERSH1P-0F-RDF-0BJECTS-1N-C0NTRDLLED-V0CABULAR1ES and 
R-39-MEMBERSH1P-0F-RDF-L1TERALS-1N-C0NTR0LLED-V0CABULAR1ES Resources 
can only be members of listed controlled vocabularies. 


36.1 Simple Example 


# DSP: 

bookDescriptionXemplate 

a dsp:DescriptionTemplate ; 
dsp:resourceClass swrciBook ; 
dsp:statementTemplate [ 

a dsp:NonLiteralStatementTemplate ; 
























7 


10 

11 


dsp:property determs:subject ; 
dsprnonLiteralConstraint [ 

a dsp:NonLiteralConstraint ; 
dsprvalueClass skos:Concept ; 

dsprvocabularyEncodingScheme BookSubjects, BookTopics, BookCategories ] ] . 


skos; Concept resources can only be members of the listed controlled vocab¬ 
ularies. 


A = Concept n B 
B = \/inScheme.C 

C = ConceptScheme n {{BookSubjects} u {BookTopics} u {BookCategories}) 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

subject 

- 

A 

range 

- 

class 

A 

- 

- 

Concept, B 

n 

- 

property 

B 

inScheme 

- 

C 

V 

- 

class 

C 

- 

- 

ConceptScheme, D 

n 

- 

class 

D 

- 

- 

{BookSubjects}, {BookTopics}, {BookCategories} 

u 

- 


1 

2 

3 

4 

5 

6 
7 


10 


# valid data: 

Artficialintelligence 
a swretBook ; 

determs:subject ComputerScience . 
ComputerScience 

a skos:Concept ; 
dcam:memberOf BookSubjects ; 
skos:inScheme BookSubjects . 
BookSubjects 

a skos:ConceptScheme . 


1 # invalid data: 

2 Artficialintelligence 

3 a swrc:Book ; 

4 determs:subject ComputerScience . 

5 ComputerScience 

6 a skos:Concept ; 

7 dcam:memberOf BooksAboutBirds ; 

8 skos:inScheme BooksAboutBirds ; 

9 dcam:memberOf BookSubjects ; 

10 skos:inScheme BookSubjects . 

11 BookSubjects 

12 a skos:ConceptScheme . 


The related subject (ComputerScience) is a member of a controlled vocab¬ 
ulary (BooksAboutBirds) which is not part of the list of allowed controlled 
vocabularies. 


37 IRI Pattern Matching 


IRI Pattern Matching corresponds to the requirements 



- R-21-IRI-PATTERN-MATCHING-ON-RDF-SUBJECTS, 

- R-22-IRI-PATTERN-MATCHING-0N-RDF-DBJECTS and 

- R-23-IRI-PATTERN-MATCHING-0N-RDF-PR0PERTIES 

indicating IRI pattern matching on subjects, properties, and objects. 

Not expressible in DL! 


38 Literal Pattern Matching 

Literal Pattern Matching corresponds to the requirement 
R-44-PATTERN-MATCHING-0N-RDF-LITERALS. indicating pattern matching on lit¬ 
erals. 


38.1 Simple Example 


# OWL 2 DL (functional-style syntax); 

DeclarationC DatatypeC SSN ) ) 

DatatypeDefinition( 

SSN 

DatatypeRestrictionC xsd:string xsdipattern "[0-9]{3}-[0-9]{2}—[0-9]{4}" ) ) 
DataPropertyRange( hasSSN SSN ) 


# OWL 2 DL (turtle syntax): 

SSN 

a rdfsrDatatype ; 
owl:equivalentClass [ 
a rdfs:Datatype ; 
owl:onDatatype xsd:string ; 
owl:withRestrictions ( 

[ xsdrpattern "[0-9]{3}-[0-9]{2}-[0-9]{4}" ] ) ] . 
hasSSN rdfstreinge SSN . 


A social security number is a string that matches the given regular expression. 
The second axiom defines SSN as an abbreviation for a datatype restriction 
on xsd:string. The first axiom explicitly declares SSN to be a datatype. The 
datatype SSN can be used just like any other datatype; for example, it is used 
in the third axiom to define the range of the hasSSN property. 

# valid data: 

TimBernersLee 

hasSSN "123-45-6789"‘~SSN . 


# invalid data: 

TimBernersLee 

hasSSN "123456789"~~SSN . 


Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

|c. value 

class 

SSN 

- 

- 

xsd:string 

xsd:pattern 

lEBaEBaBBM 






















38.2 Simple Example 

There are multiple use cases associated with the requirement to match literals 
according to given patterns. 

Luke’s droids can only have the numbers ” R2-D2” or ” C-3P0”. The universal 
restriction part of this constraint can be expressed by OWL 2 DL; LukesDroids 
E V droidNumber. DroidNumber. The restriction of the datatype DroidNumber, 
however, cannot be expressed in DL, but OWL 2 DL can be used anyway: 

DroidNumber 

a rdfs:Datatype ; 
owl:equivalentClass [ 
a rdfs:Datatype ; 
owl:onDatatype xsd:string ; 
owl:withRestrictions ( 

[ xsdrpattern "R2-D2|C-3P0" ] ) ] . 


The second axiom defines DroidNumber as an abbreviation for a datatype re¬ 
striction on xsd:string. The first axiom explicitly declares DroidNumber to 
be a datatype. The datatype DroidNumber can be used just like any other 
datatype like in the universal restriction above. The literal pattern matching 
constraint validates DroidNumber literals according to the stated regular ex¬ 
pression causing a constraint violation for the triples Luke hasDroid Droideka 
andDroideka droidNumber "Droideka" ""DroidNumber, but not for the triples 
Luke hasDroid R2-D2 and R2-D2 droidNumber "R2-D2"""DroidNumber. 

Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

class 

LukesDroids 

DroidNumber 

droidNumber 

- 

DroidNumber 

xsd:string 

V 

xsd:pattern 

'R2-D2|C-3PO' 


39 Negative Literal Pattern Matching 

Negative Literal Pattern Matching corresponds to the requirement 
R-44-PATTERN-MATCHING-0N-RDF-LITERALS indicating negative pattern match¬ 
ing on literals. 

# examples: 

1. dborisbn format is different from ’^([ilsSbBnN 0-9-])*$’ 

2. dbo:postCode format is different ‘!’ from ’^ [0-9]{5}$’ 

3. foaf:phone contains any letters (’[A-Za-z]’) 


39.1 Example 


# test binding (DQTP); 

dborisbn format is different ’!’ from ’^([ilsSbBnN 0-9-])*$’ 

PI => dbo:isbn 
NOP => ! 

REGEX => ’“([ilsSbBnN 0-9-])*$’ 










# DQTP: 

SELECT DISTINCT ?s WHERE { ?s Will ?value . 

FILTER ( llmvll regex(str(?value), “/.XREGEXyj ) > 


- MATCH Pattern [3] 

— PI is the property we need to check against REGEX and NOP can be a not 
operator (!) or empty. 


# valid data: 

FoundationsOfSWTechnoIogies 

dborisbn ’ISBN-13 978-1420090505’ 


# invalid data: 

HandbookOfSWTechnoIogies 

dbo:isbn ’DQI 10.1007/978-3-540-92913-0’ . 


Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

dbo:isbn 

- 

- A 

domain 

- 

class 

- A 

- 

- 

A 


- 

class 

A 

- 

- 

xsd:string 

regex 

'“([ilsSbBnN 0-9-])*' 


40 Literal Value Comparison 

Literal Value Comparison corresponds to the requirement 
R-43-L1TERAL-VALUE-CDMPARISON. Examples are: 

— dbo:deathDate before ‘<’ dbo:birthDate 

— dbo:releaseDate after ‘>’ dbo:latestReleaseDate 

— dbo:demolitionDate before ‘<’ dbo:buildingStartDate 


40.1 Simple Example 


# DQTP: 

SELECT ?s WHERE { 

?s •/.•/.? 1'/.'/. ?vl . 

?s •/.•/.P2n ?v2 . 

FILTER ( ?vl ■/.•/.OPZ'/. ?v2 ) } 


This constraint corresponds to the COMP Pattern [3]. Depending on the 
property semantics, there are cases where two different literal values must have 
a specific ordering with respect to an operator. PI and P2 are the datatype 
properties we need to compare and OP is the comparison operator (<, <=, >, 
>=, =, !=). 















# test binding (DQTP): 

dboideathDate before dbo:birthDate 

PI => dbo:deathDate 
P2 => dbo:birthDate 
OP => < 


# valid data: 


:AlbertEinstein 


dbo:birthDatG 

’ 1879-03-14’'■''xsd: date ; 

dboideathDate 

’ 1955-04-18’'“'xsd:date . 


# invalid data: 



:NeilArmstrong 



dbo:birthDatG 

’2012-08-25’ 

''■''xsd: date ; 

dboideathDate 

’1930-08-05’ 

'■“xsdidate . 


Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 


c. element 

c. value 

property 

T 

dbo:birthDate 

dbo:deathDate 


> 

- 


40.2 Simple Example 

Duplicate strings are not allowed: 


1 

dc:subject 

"f oo' 

'(Sen 

2 

dc:subject 

"f oo' 

'@fr 

3 

dc:subject 

"bar' 

’@fr 

4 

dc:subject 

"f oo' 



There are no identical strings. 

Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

dc:subject 

dc:subject 

xsd:string 

7^ 

- 


41 Negative Literal Ranges 

Negative Literal Ranges corresponds to the requirement R-142-NEGATIVE- 
RANGES-DF-RDF-LITERAL-VALUES. The literal value of a resource (having a cer¬ 
tain type) must (not) be within a specific range. PI is a data property of an in¬ 
stance of class T1 and its literal value must be between the range of [Vmin,Viiiax] 
or outside ( ‘!’ ). 



























41.1 Simple Example 


— dbo:height of a dbo:Person is not within [0.4,2.5] 

41.2 Simple Example 

— geodat of a spatiabFeature is not within [-90,90] 

41.3 Simple Example 

— geodong of a gmhFeature must be in range [-180,180] 


42 Literal Ranges 

Literal Ranges corresponds to the requirement R-45-RANGES-DF-RDF-LITERAL- 
VALUES. PI is a data property (of an instance of class Cl) and its literal value 
must be between the range of lVmin,Vmax]- 


42.1 Example 


1 # OWL 2 DL (functional-style syntax); 

2 DeclarationC DatatypeC NumberPlayersPerWorldCupTeam ) ) 

3 DatatypeDefinition( 

4 NumberPlayersPerWorldCupTeam 

5 DatatypeRestrictionC 

6 xsd:nonNegativeInteger 

7 xsd:minlnclusive "l"'''‘xsd:nonNegativeInteger 

8 xsdrmaxinclusive "23"'‘~xsd:nonNegativeInteger ) ) 

9 DataPropertyRange( position NumberPlayersPerWorldCupTeam ) 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 


# OWL 2 DL (turtle syntax): 

NumberPlayersPerWorldCupTeam 
a rdfs:Datatype ; 
owl:equivalentClass [ 
a rdfs:Datatype ; 

owl:onDatatype xsdinonNegativelnteger ; 
owlrwithRestrictions ( 

[ xsdrmininclusive "l"'‘~xsd:nonNegativeInteger ] 

[ xsdrmaxinclusive "23"~'‘xsd:nonNegativeInteger ] ) ] . 
position rdfs:range NumberPlayersPerWorldCupTeam . 


The data range ’NumberPlayersPerWorldCupTeam’ contains the non nega¬ 
tive integers 1 to 23, as each world cup team can only have 23 football players 
at most. 


1 # valid data: 

2 MarioGoetze 

3 position "ID"'"':NumberPlayersPerWorldCupTeam . 


1 # invalid data: 

2 MarioGoetze 

3 position "DD"'"':NumberPlayersPerWorldCupTeam . 












Not expressible in DL! 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

NumberPlayersPerWorldCupTeam 

- 

- 

^1, ^23 

n 

- 

class 


- 

- 

xsd: non Negative! nteger 


1 

class 

^23 

- 

- 

xsd: non Negati vel nteger 


23 


43 Ordering 

Ordering corresponds to the requirements R-121-SPECIFY-0RDER-0F-RDF-RESOURCES 
and R-217-DEFINE-0RDER-F0R-F0RMS/DISPLAY. With this constraint objects of 
object properties can be ordered as well as literals of data properties and objects 
of object properties. 

43.1 Simple Example 

Define the order of the property listElement for the class rdf :List. List ele¬ 
ments are of datatype xsd: string. 

Not expressible in DL! 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

rdf: List 

listElement 

- 

xsd:string 

order 

1 


43.2 Simple Example 

Property p should be ordered, i.e., point to a list (rdLList) of values. 

Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

P 

- 

- 

ordered property 

- 


44 Validation Levels 

Validation Levels corresponds to the requirements 

- R-205-VARY1NG-LEVELS-DF-ERRDR, 

- R-135-C0NSTRA1NT-LEVELS, 

- R-158-SEVER1TY-LEVELS-DF-C0NSTRA1NT-V10LAT10NS, and 

- R-193-MULT1PLE-C0NSTRA1NT-VAL1DAT10N-EXECUT10N-LEVELS. 

Different levels of severity, priority should be assigned to constraints. Pos¬ 
sible validation levels could be: informational, warning, error, fail, should, rec¬ 
ommended, must, may, optional, closed (only this) constraints, open (at least 
this). 


Not expressible in DL! 



















45 String Operations 


String Operations corresponds to the requirement R-194-PR0VIDE-STRING- 
FUNCTIONS-FOR-RDF-LITERALS. Some constraints require building new strings 
out of other strings. Calculating the string length would also be another con¬ 
straint of this type. 


45.1 Simple Example 

The length of strings of the property hasISBN for the context class Book must 
be exactly 3. 


Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

Book 

hasISBN 

- 

xsd:string 

length 

3 


46 Context-Specific Valid Classes 


Context-Specific Valid Classes corresponds to the requirements 
R-209-VAL1D-CLASSES. What types of resources (rdfitype) are valid in a specific 
context? Context can be an input stream, a data creation function, or an API. 


46.1 Simple Example 

Within the context AP (application profile) the classes Book and Paper are valid. 


Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

AP 

- 

- 

Book, Paper 

context-specific valid classes 

true 


47 Context-Specific Valid Properties 


Context-Specific Valid Properties corresponds to the requirement R-210- 
VALID-PRDPERTIES. What properties can be used within this context? Context 
can be an data receipt function, data creation function, or API. 



47.1 Simple Example 


Within the context AP (application profile) the properties determs: subject and 
determs: title are invalid. 


Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 


c. element 

c. value 

property 

AP 

dcterms:subject, dcterms:title 

- 


context-specific valid properties 

false 


48 Default Values 

Default Values corresponds to the requirements R-31-DEFAULT-VALUES-0F-RDF- 
OBJECTS and R-38-DEFAULT-VALUES-0F-RDF-LITERALS. Default values for ob¬ 
jects and literals are inferred automatically. It should be possible to declare the 
default value for a given property, e.g. so that input forms can be pre-populated 
and to insert a required property that is missing in a web service call. 


48.1 Simple Example 

Jedis have only 1 blue laser sword per default. Siths, in contrast, normally have 
2 red laser swords. 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 


# rule (SPIN) 

# - 


owl:Thing 

spin:rule [ 

a sp:Construct ; 
sp:text """ 

CONSTRUCT -C 

?this laserSwordColor "blue"'■'‘xsd:string ; 

?this numberLaserSwords "1"^“xsd:nonNegativeinteger . 

} 

WHERE -C 

?this a Jedi . 

> . ; ] . 

owl:Thing 

spin:rule [ 

a sp:Construct ; 
sp:text """ 

CONSTRUCT -C 


?this laserSwordColor "red"““xsd:string ; 

?this numberLaserSwords "2"““xsd:nonNegativeinteger . 

} 

WHERE -C 


?this a Sith . 


} """ ; ] . 


1 # data: 

2 Joda a Jedi . 

3 DarthSidious a Sith . 



















# inferred triples: 

Joda 

laserSwordColor "blue "'■'‘xsd: string ; 
numberLaserSwords "l"'‘~xsd:nonNegativeInteger . 
DarthSidious 

laserSwordColor "red"'“'xsd:string ; 
numberLaserSwords "2"''''xsd:nonNegativeInteger . 


Not expresible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. 

list 

classes 

c. element 

c. value 

property 

Jedi 

laserSwordColor 

- 


- 

default values 

'blue' 

property 

Jedi 

numberLaserSwords 

- 


- 

default values 

'1' 

property 

Sith 

laserSwordColor 

- 


- 

default values 

'red’ 

property 

Sith 

numberLaserSwords 

- 


- 

default values 

'2' 


49 Mathematical Operations 


Mathematical Operations corresponds to the requirements 

— R-42-MATHEMATICAL-0PERATI0NS and 

— R-41-STATISTICAL-CDMPUTATI0NS. 

Examples are: 

— adding 2 dates 

— add number of days to start date 

— area = width * height 

— Statistical Computations: average, mean, sum 


49.1 Simple Example 

Calculate rectangle areas. 


Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

Rectangle 

area 

width, height 

xsddnteger 

multiplication 

- 


50 Language Tag Matching 

Language Tag Matching corresponds to the requirement 
R-47-LANGUAGE-TAG-MATCH1NG. 




50.1 Simple Example 

Only English names are allowed. 

Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

name 

- 

- 

language tag 

'en' 


51 Language Tag Cardinality 


Language Tag Cardinality corresponds to the requirements 

- R-49-RDF-LITERALS-HAVING-AT-M0ST-0NE-LANGUAGE-TAG and 

- R-48-MISSING-LANGUAGE-TAGS. 

51.1 Simple Example 

Check that no language is used more than once per property 


# DQTP: 

SELECT DISTINCT ?s WHERE ■[ ?s •/.■/.?I'/.'/. 7c 
BIND ( lang(7c) AS ?I ) 

FILTER (isLlteral (?c) M lang(?c) = '/.•/.Vl'/.X)} 
GROUP BY ?s HAVING COUNT (71) > 1 


This corresponds to the test pattern DNELANGPattern [3]. A literal value 
should contain at most 1 literal for a language. PI is the property containing the 
literal and VI is the language we want to check. 

# test binding (DQTP): 

PI => foaf:name 
VI => en 


A single English (“en”) foaf :najne. 


# valid data; 

:LeiaSkywalker 

foaf:name ’Leia Skywalker’Oen . 


# invalid data: 

:LeiaSkywalker 

foaf:name ’Leia Skywalker’Sen ; 
foaf:name ’Leia’Qen . 


Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

foaf:name 

- 

- 

language tag exact cardinality 

1 

























52 Whitespace Handling 


Whitespace Handling corresponds to the requirement R-50-WHITESPACE- 
HANDLING-OF-RDF-LITERALS. Avoid whitespaces in literals neither leading nor 
trailing white spaces. 

52.1 Simple Example 

Check if literals of the property p do not include whitespaces. 

Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

P 

- 

- 

whitespace 

- 


53 HTML Handling 

HTML Handling corresponds to the requirement R-51-HTML-HANDL1NG-0F-RDF- 
LITERALS. Check if there are no HTML tags included in literals (of specific data 
properties within the context of specific classes). 

53.1 Simple Example 

Check if literals of the property p of the class C do not include HTML tags. 

Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

c 

P 

- 

- 

HTML 

- 


54 Required Properties 

Required Properties corresponds to the requirement R-68-REQU1RED-PR0PERT1ES. 

54.1 Simple Example 

For persons the property hasAncestor has to be stated pointing to persons. 

Person E 3hasAncestor.Person 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 


c. element 

c. value 

property 

Person 

hasAncestor 

- 


3 

- 








55 Optional Properties 

Optional Properties corresponds to the requirement R-69-DPTI0NAL-PR0PERTIES. 


55.1 Simple Example 

For persons the property hasAncestor pointing to persons is optional. 

3has Ancestor. Per son E Person 
Same as the definition of domains. 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

3 hasAncestor.Person 

hasAncestor 

- 

Person 

3 

- 

class 

Person 

- 

- 

3 hasAncestor. Person 


- 


syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 


c. element 

c. value 

property 

Person 

hasAncestor 

- 


optional 

- 


56 Repeatable Properties 

Repeatable Properties corresponds to the requirement 
R-70-REPEATABLE-PR0PERT1ES. 

56.1 Simple Example 

The property commandsVessel is repeatable for individuals of the class Captain. 
Captain IcommandsVessel.T 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 


c. element 

c. value 

property 

Captain 

commandsVessel 

- 



1 


syntactic sugar: 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 


c. element 

c. value 

property 

Captain 

commandsVessel 

- 


repeatable 

- 












































57 Conditional Properties 


Conditional Properties corresponds to the requirement 
R-71-CDNDITI0NAL-PR0PERTIES. 

Multiple conditions are possible: 

— universal quantification on object and data properties, 

— existential quantification on object and data properties, 

— if specific properties are present, then specific other properties also have to 
be present 

57.1 Simple Example 

If an individual has a parentOf property relationship, then this individual also 
has a ancestorOf property relationship. 

parentOf E ancestorOf 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

parentOf 

ancestorOf 

T 




58 Recommended Properties 

Recommended Properties corresponds to the requirement 
R-72-RECDMMENDED-PR0PERT1ES. Which properties are not required but recom¬ 
mended within a particular context. 

58.1 Simple Example 

Property p is recommended to use within the context of the class C. 

Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

C 

P 

- 

- 

recommended 

- 


59 Negative Property Constraints 

Negative Property Constraints corresponds to the requirements 

- R-52-NEGAT1VE-0BJECT-PRDPERTY-C0NSTRA1NTS and 

- R-53-NEGAT1VE-DATA-PRDPERTY-C0NSTRA1NTS. 

Instances of a specific class must not have some object property. In OWL 2 DL, 
this can be expressed as follows: Obj ectComplementOf ( Obj ectSomeValuesFrom 
( ObjectPropertyExpression owl:Thing ) ). 



59.1 Example 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 


# ShEx: 

<FeelingForcG> { 

feelingForce (true) , 
attitute xsd: string )■ 

<JGdiMGntor> { 

feelingForce (true) , 
attitute (’good’) , 
laserSwordColor xsd:string , 
numberLaserSwords xsd:nonNegativeInteger , 
mentorOf (9<JediStudent> , 

IstudentOf @<JediMentor> } 

<JGdiStudent> { 

feelingForce (true) , 
attitute (’good’) , 
laserSwordColor xsd:string , 
numberLaserSwords xsd:nonNegativeInteger , 
! mentorOf (9<JediStudent> , 
studentOf @<JediMentor> }■ 


A matching triple has any predicate except those excluded by the ’!’ operator. 


1 # individuals matching ’FeelingForce’ and ’JediMentor’ data shapes: 

2 Obi-Wan 

3 feelingForce true ; 

4 attitute ’good’ ; 

5 laserSwordColor ’blue’ ; 

6 numberLaserSwords ’1’'“'xsd:nonWegativelnteger ; 

7 mentorOf Anakin . 


1 # individuals matching ’FeelingForce’ and ’JediStudent’ data shapes: 

2 Anakin 

3 feelingForce true ; 

4 attitute ’good’ ; 

5 laserSwordColor ’blue’ ; 

6 numberLaserSwords ’1’'“'xsd:nonWegativelnteger ; 

7 StudentOf Obi-Wan . 


JediMentor E ^(IstudentOf.JediMentor) 


Mapping to RDF-CO: 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

3 studentOf.JediMentor 

StudentOf 

- 

JediMentor 

3 

- 

class 

JediMentor 

- 

- 

3 StudentOf.JediMentor 

- 

- 


60 Handle RDF Collections 

Handle RDF Collections corresponds to the requirement R-120-HANDLE-RDF- 
COLLECTIDNS. Examples are: 

— size of collection 

— first / last element of list must be a specific literal 

— compare elements of collection 

















1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

1 

2 

3 

1 

2 

1 
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— are collections identical? 

— actions on RDF listS 

— 2. list element equals ’XXX’ 

— Does the list have more than 10 elements? 

60.1 Example 

Get 2. list element: 

# SPIN: 
getListItem 

a spintFunction ; rdfs;subClassOf spin:Functions ; 
spin:constraint [ 

rdf:type spl:Argument ; 
spl:predicate sp:argl ; 
spl:valueType rdf:List ; 
rdfs:comment "list" ; ] ; 
spin:constraint [ 

rdf:type spl:Argument ; 
spl:predicate sp:arg2 ; 
spl:valueType xsd:nonNegativeInteger ; 
rdfs:comment "item position (starting with 0)" ; ] ; 
spin:body [ 

a sp:SELECT ; 
sp:text """ 

SELECT ?item 
WHERE i 

?argl contents/rdf:rest{?arg2}/rdf:first ?item }""";] ; 
spin:returnType rdfs:Resource . 


# data: 

Jinn students 

( Xanatos Kenobi ) 


# SPIN: 

BIND ( getListItemC ?list, "l"xsd:nonNegativeInteger ) AS ?listltem ) 


— SPIN function call 

— retrieves the 2. item from the list (2. student of Jedi mentor Jinn) 

# result: 

Kenobi 


Not expressible in DL! 


60.2 Simple Example 

Append a string list element ’list element’ to a list the property p of the class C 
is pointing to. 

Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

C 

P 

- 

xsd:string 

append list element 

'list element' 


See http://www.snee.com/bobdc.blog/2014/04/rdf-lists-and-sparql.html 


















61 Recursive Queries 


Recursive Queries corresponds to the requirement R-222-RECURSIVE-QUERIES. 
If we want to define Resource Shapes, remember that it is a recursive language 
(the valueShape of a Resource Shape is in turn another Resource Shape). There 
is no way to express that in SPARQL without hand-waving ’’and then you call 
the function again here” or ’’and then you embed this operation here” text. 
The embedding trick doesn’t work in the general case because SPARQL can’t 
express recursive queries, e.g. ’’test that this Issue is valid and all of the Issues 
that references, recursively”. Most SPARQL engines already have functions that 
go beyond the official SPARQL 1.1 spec. The cost of that sounds manageable. 

61.1 Simple Example 


# ShEx: 

IssueShape { 

related QlssueShape* 

} 


IssueShape Irelated.IssueShape 


Mapping to RDF-CO; 



context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

IssueShape 

related 

- 

IssueShape 


1 


62 Value is Valid for Datatype 

Make sure that a value is valid for its datatype. 


62.1 Simple Example 

A date is really a date, as an example. SPARQL regex can be used for this 
purpose. 


62.2 Simple Example 


# SPIN: 

FILTER ( datatypeC ?shoeSize ) = xsd:nonNegativeInteger ) 
isNumeric ( ?shoeSize ) 


The datatype of ?showSize is xsdinonNegativeInteger. The datatype is really 
numeric. 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

shoeSize 

- 

xsd:nonNegativelnteger 

value valid for datatype 

- 























63 Individual Equality 


Individual equality states that two different names are known to refer to the 
same individual [3]. 


63.1 Simple Example 


{julia} = {John} 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

{julia} 

- 

- 

{John} 


- 

class 

{John} 

- 

- 

{julia} 


- 


64 Individual Inequality 

This is by default because of the UNA. 


64.1 Simple Example 


{julia} A [john] 

Asserts that Julia and John are actually different individuals. 

Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

{julia} 

- 

- 

{john} 


- 

class 

{john} 

- 

- 

{julia} 

7 ^ 

- 


65 Equivalent Properties 

An equivalent object properties axiom EquivalentObjectProperties( OPEl ... 
OPEn ) states that all of the object property expressions OPEi, 1 ^ i ^ n, 
are semantically equivalent to each other. This axiom allows one to use each 
OPEi as a synonym for each OPEj — that is, in any expression in the ontology 
containing such an axiom, OPEi can be replaced with OPEj without affecting the 
meaning of the ontology. The axiom EquivalentObjectProperties( OPEI OPE2 
) is equivalent to the following two axioms SubObjectPropertyOf( OPEI OPE2 
) and SubObjectPropertyOf( OPE2 OPEI ). 

An equivalent data properties axiom EquivalentDataProperties( DPEl ... 
DPEn ) states that all the data property expressions DPEi, 1 ^ i ^ n, are 
semantically equivalent to each other. This axiom allows one to use each DPEi as 
a synonym for each DPEj — that is, in any expression in the ontology containing 
such an axiom, DPEi can be replaced with DPEj without affecting the meaning 
of the ontology. The axiom EquivalentDataProperties( DPEI DPE2 ) can be 
seen as a syntactic shortcut for the following axiom SubDataPropertyOf( DPEI 
DPE2 ) and SubDataPropertyOf( DPE2 DPEI ). 




















65.1 Simple Example 


# OWL 2: 

hasBrother owl:equivalentProperty hasMaleSibling . 
Chris hasBrother Stewie . 

Stewie hasMaleSibling Chris . 


entailments: 


Chris hasMaleSibling Stewie . 
Stewie hasBrother Chris . 


hasBrother E hasMaleSibling n hasMaleSibling c hasBrother 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 


c. element 

c. value 

property 

T 

hasBrother 

hasMaleSibling 

- 



property 

T 

hasMaleSibling 

has Brother 

- 




hasBrother = hasM aleSibling 


66 Property Assertions 

Property Assertions corresponds to the requirement R-96-PR0PERTY-ASSERTI0NS 
and includes positive property assertions and negative property assertions. A 
positive object property assertion ObjectPropertyAssertion( OPE al a2 ) states 
that the individnal al is connected by the object property expression OPE to 
the individual a2. A negative object property assertion NegativeObjectProp- 
ertyAssertion( OPE al a2 ) states that the individual al is not connected by the 
object property expression OPE to the individual a2. A positive data property 
assertion DataPropertyAssertion( DPE a It ) states that the individual a is con¬ 
nected by the data property expression DPE to the literal It. A negative data 
property assertion NegativeDataPropertyAssertion( DPE a It ) states that the 
individual a is not connected by the data property expression DPE to the literal 
It. 

66.1 Simple Example 

# OWL 2: 

NegativeObjectPropertyAssertionC hasSon Peter Meg ) 


Meg is not a son of Peter. 

hasSon{Peter,Meg) 

The negation of such an assertion is not necessary, as it’s meaningless! 

Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 


c. element 

c. value 

property 

{Peter} 

hasSon 

- 



- 






























66.2 Simple Example 


# OWL 2: 

DataPropertyAssertionC thasAge :Meg "17"'‘~xsd: integer ) 


Meg is seventeen years old. 

hasAge(Meg,''n""xsd : integer) 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

{Meg} 

hasAge 

- 

- 


" 17"" xsd: integer 


67 Functional Properties 

An object property functionality axiom FunctionalObjectProperty( OPE ) states 
that the object property expression OPE is functional — that is, for each individ¬ 
ual X, there can be at most one distinct individual y such that x is connected by 
OPE to y. Each such axiom can be seen as a syntactic shortcut for the following 
axiom: SubClassOf( owhThing ObjectMaxCardinality( 1 OPE ) ). 


67.1 Simple Example 


# OWL 2 : 

hasFather rdf:type owl:FunctionalProperty . 
Stewie hasFather Peter . 

Stewie hasFather Peter_Griffin . 


Each object can have at most one father, 
entailment: 

Peter_Griffin owlisameAs Peter . 


(funct hasFather) 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 


c. element 

c. value 

property 

T 

hasFather 

- 


functional 

- 


68 Inverse-Functional Properties 

An object property inverse functionality axiom InverseFunctionalObjectProp- 
erty( OPE ) states that the object property expression OPE is inverse-functional 
- that is, for each individual x, there can be at most one individual y such that y 
is connected by OPE with x. Each such axiom can be seen as a syntactic short¬ 
cut for the following axiom: SubClassOf( owhThing ObjectMaxCardinality( 1 
ObjectInverseOf( OPE ) ) ). 















68.1 Simple Example 


# OWL 2: 

fatherOf rdf:type owl:InverseFunctionalProperty . 
Peter fatherOf Stewie . 

Peter_Griffin fatherOf Stewie . 


Each object can have at most one father. 
Entailment: 

Peter owl:sameAs Peter_Griffin . 


(funct hasFather ) 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

hasFather” 

hasFather 

- 

inverse 

- 

property 

T 

hasFather” 

- 

- 

functional 

- 


69 Value Restrictions 

Individual Value Restrictions: A has-value class expression ObjectHasValue( 
OPE a ) consists of an object property expression OPE and an individual a, 
and it contains all those individuals that are connected by OPE to a. Each such 
class expression can be seen as a syntactic shortcut for the class expression Ob- 
jectSomeValuesFrom( OPE ObjectOneOf( a ) ). Literal Value Restrictions: A 
has-value class expression DataHasValue( DPE It ) consists of a data property 
expression DPE and a literal It, and it contains all those individuals that are 
connected by DPE to It. Each such class expression can be seen as a syntactic 
shortcut for the class expression DataSomeValuesFrom( DPE DataOneOf( It ) 
)■ 

69.1 Simple Example 

FatherO f Stewie E 3 fatherOf .{Stewie} 


# OWL 2: 

Peter fatherOf Stewie . 
ObjectHasValue( fatherOf Stewie ) 


The has-value class expression contains those individuals that are connected 
through the fatherOf property with the individual Stewie. Peter is classified 
as its instance. 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

FatherOfStewie 

fatherOf 

- 

{Stewie} 

3 







70 Self Restrictions 


A self-restriction ObjectHasSelf( OPE ) consists of an object property expres¬ 
sion OPE, and it contains all those individuals that are connected by OPE to 
themselves. 


70.1 Simple Example 


# OWL 2: 

Peter likes Peter . 
ObjectHasSelf( likes ) 


LikesThemselves E 3 likes.Self 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

1 classes 

c. element 

c. value 

property 

3 likes . Self 

likes 

- 

Self 


3 


class 

LikesThemselves 

- 

- 

T, 3 likes . 

Self 




The self-restriction contains those individuals that like themselves. Peter is 
classified as its instance. 


71 Data Property Facets 

Data Property Facets corresponds to the requirement R-46-C0NSTRAINING-FACETS. 

For datatype properties it should be possible to declare frequently needed ” facets” 
to drive user interfaces and validate input against simple conditions, including 
min/max value, regular expressions, string length etc. similar to XSD datatypes. 
Constraining facets to restrict datatypes of RDF literals. Constraining facets may 
be: xsd:length, xsd:minLength, xsd:maxLength, xsdipattern, xsd:enumeration, 
xsdiwhiteSpace, xsd:maxlnclusive, xsd:maxExclusive, xsdiminExclusive, xsdimininclusive, 
xsditotalDigits, xsd:fractionDigits. 


71.1 Simple Example 

string matches regular expression 


# OWL 2 QL (functional-style syntax); 

DeclarationC DatatypeC SSN ) ) 

DatatypeDefinition( 

SSN 

DatatypeRestrictionC xsd:string xsdipattern " [0-9] {3}-[0-9] {2}--[0-9] {4}" ) ) 
DataPropertyRange( hasSSN SSN ) 






















# OWL 2 QL (turtle syntax): 

SSN 

a rdfs:Datatype ; 
owl:equivalentClass [ 
a rdfs:Datatype ; 
owl:onDatatype xsd:string ; 
owlrwithRestrictions ( 

[ xsdipattern " [0-9] {3)--[0-9] {2}-[0-9] {4}" ] ) ] . 
hasSSN rdfs:rcinge SSN . 


A social security number is a string that matches the given regular expression. 
The second axiom defines SSN as an abbreviation for a datatype restriction 
on xsd:string. The first axiom explicitly declares SSN to be a datatype. The 
datatype SSN can be used just like any other datatype; for example, it is used 
in the third axiom to define the range of the hasSSN property. 


# valid data: 

TimBernersLee 

hasSSN "123-45-6789"‘~SSN . 


# invalid data: 

TimBernersLee 

hasSSN "123456789"‘~SSN . 


Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

SSN 

- 

- 

xsd:string 

xsd:pattern 

'[0-9]3-[0-9]2-[0-9]4' 


72 Primary Key Properties 

It is often useful to declare a given (datatype) property as the ’’primary key” 
of a class, so that the system can enforce uniqueness and also automatically 
build URIs from user input and data imported from relational databases or 
spreadsheets. 

72.1 Simple Example 

The Primary Key Properties constraint is often useful to declare a given (datatype) 
property as the ’’primary key” of a class, so that a system can enforce uniqueness. 
Starfleet officers, e.g., are uniquely identified by their command authorization 
code (e.g. to activate and cancel auto-destruct sequences). It means that the 
property commandAuthorizationCode is inverse functional - mapped to DL and 
the RDF-CO as follows: 


(funct commandAuthorizationCode ) 





Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

commandAuthorizationCode” 

commandAuthorizationCode” 

- 

inverse 

- 

property 

T 

commandAuthorizationCode” 

- 

- 

functional 

- 


Keys, however, are even more general, i.e., a generalization of inverse func¬ 
tional properties [6]. A key can be a datatype property, an object property, or a 
chain of properties. For this generalization purposes, as there are different sorts 
of key, and as keys can lead to undecidability, DL is extended with key boxes 
and a special keyfor construct [S] . This leads to the following DL and RDF-CO 
mappings (only one simple property constraint): 

commandAuthorizationCode keyfor StarfleetOfficer 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

StarFleetOfFicer 

commandAuthorizationCode 

- 

- 

keyfor 

- 


73 Use Sub-Super Relations in Validation 

Exploiting Class/Property Specialization Ontology Axioms corresponds 
to the requirement R-224-instcLnce-level-data-validation-exploitingclass/ 
property-specialization-axioms-in-ontologies. Validation of instances data 
(direct or indirect) exploiting the subclass or sub-property link in a given on¬ 
tology. This validation can indicate when the data is verbose (redundant) or 
expressed at a too general level, and could be improved. Examples are: 

— If dc:date and one of its sub-properties determs:created or dcterms:issued are 
present, check that the value in dc:date is not redundant with determs:created 
or dcterms:issued for ingestion 

— Check if dc:rights has the same value than edm:rights either as rdhresource 
or literal, if yes dc:rights is redundant 

— If one or more dc:coverage are present, suggest the use of one of its sub¬ 
properties, determs spatial or dcterms:temporal. 


73.1 Simple Example 

If dc:date and one of its sub-properties determs:created or determs:issued are 
present, check that the value in dc:date is not redundant with determs:created 
or determs :issued for ingestion 

Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

T 

dc:date 

dctermsxreated, dcterms:issued 

- 

not redundant 

- 





























74 Cardinality Shortcuts 


In most Library applications, cardinality shortcuts tend to appear in pairs, with 
repeatable / non-repeatable establishing maximum cardinality and optional / 
mandatory establishing minimum cardinality. 

— Optional & Non-Repeatable = [0,1] 

— Optional & Repeatable = [0,*] 

— Mandatory & Non-Repeatable = [1,1] 

— Mandatory & Repatable = [1,*] 

Can be expressed in DL using minimum and maximum cardinality restrictions. 
We propose to use syntactic sugar instead: 

Mapping to RDF-CO; 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

C 

P 

- 

- 

optional and non-repeatable 

- 


75 Aggregations 

Some constraints require aggregating multiple values, especially via COUNT, 
MIN and MAX. 

75.1 Simple Example 

p = COUNT (q) 

Context class is C. 

Not expressible in DL 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

property 

C 

P 

q 

- 

count 

- 


76 Provenance 

Any provenance information must be available for instances of given classes. 


76.1 Simple Example 

For publications, any provenance information must be available. 

Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

Publication 

- 

- 

- 

provenance 

- 



77 Data Model Consistency 


Is the data consistent with the intended semantics of the data model? Such 
validation rules ensure the integrity of the data according to the data model. 

Not expressible in DL! 


78 Strnctnre 

SKOS is based on RDF, which is a graph-based data model. Therefore we can 
concentrate on the vocabulary’s graph-based structure for assessing the quality 
of SKOS vocabularies and apply graph- and network-analysis techniques. 

Not expressible in DL! 

79 Labeling and Docnmentation 

Not expressible in DL! 

80 Vocabulary 

Vocabularies should not invent any new terms or use deprecated elements. 


80.1 Simple Example 


Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

T 

- 

- 

- 

vocabulary 

- 


81 HTTP URI Scheme Violation 

81.1 Simple Example 


Not expressible in DL! 


Mapping to RDF-CO: 


c. set 

context class 

left p. list 

right p. list 

classes 

c. element 

c. value 

class 

T 

- 

- 

- 

HTTP URI Scheme Violation 

- 



82 Evaluation 


82.1 Evaluation of Constraint Languages 


We evaluated to which extend the most promising five constraint languages ful¬ 
fill each requirement. Tilde means that this constraint may be fulfilled by that 
particular constraint language - either by limitations, workarounds, or exten¬ 
sions. We also evaluated if a specific constraint is fulfilled by OWL 2 QL or if 
the more expressive OWL 2 DL is needed. Inferencing may be performed prior 
to validating constraints. This is marked with an asterisk. 
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82.2 Evaluation of Constraints Classes 

We evaluated to which extend the most promising five constraint languages 
fulfill each of the overall 74 requirements to formulate RDF constraints [2]- If 
a constraint can be expressed in DL, we added the mapping to DL and to the 
generic constraint. If a constraint cannot be expressed in DL, we only added 
the mapping to the generic constraint. Therefore, we show that each constraint 
can be mapped to a generic constraint. The following table shows the absolute 
numbers and the relative percentages for each of the three dimensions to classify 
constraints: 


Constraint Classes 

# 

¥o 

Property Constraints 

49 

60 (60.49) 

Class Constraints 

20 

25 (24.96) 

Property and Class Constraints 

12 

15 (14.81) 

Simple Constraints 

49 

60 (60.49) 

Simple Constraints (Syntactic Sugar) 

11 

14 (13.58) 

Complex Constraints 

21 

26 (25.93) 

DL Expressible 

52 

64 (64.2) 

DL Not Expressible 

29 

36 (35.80) 

Total 

81 

100 


legend of the detailed evaluation: 

— property constraint: property constraint (y^) vs. class constraint (X) vs. 
property and class constraints (~) 

— simple constraint: simple constraint (v^) vs. simple constraint [syntactic 
sugar] (~) vs. complex constraint (X) 



















— DL: expressible in DL (y^) vs. not expressible in DL (X) 










constraint 

property c. 

simple c. 

DL 

Context-Specific Valid Classes 

K 

nA 

X 

Context-Specific Valid Properties 

y 


X 

^Default Values 

y 


X 

Mathematical Operations 

y 


X 

Language Tag Matching 

y 


X 

Language Tag Cardinality 

y 


X 

Whitespace Handling 

y 


X 

HTML Handling 

y 


X 

Conditional Properties 

y 



Recommended Properties 

y 


X 

Handle RDF Collections 

y 


X 

Value is Valid for Datatype 

y 


X 

Use Sub-Super Relations in Validation 

y 


X 

*Cardinality Shortcuts 

y 



Aggregations 

y 


X 

*Class-Specific Irreflexive Object Properties 

y 



Provenance 

X 


X 

Data Model Consistency 


X 

X 

Structure 


X 

X 

Labeling and Documentation 


X 

X 

Vocabulary 

X 


X 

HTTP URI Scheme Violation 

X 


X 


Constraints can be classified as property constraints and class constraints. 
Two thirds of the total amount of constraints are property constraints, one fifth 
are class constraints, and approx. 10% are composed of both property and class 
constraints. Constraints may be either atomic (simple constraints) or created 
out of simple and/or complex constraints (complex constraints). Almost two 
thirds are simple constraints, a quarter are complex constraints. Almost 15 per¬ 
cent are complex constraints which can be formulated as simple constraints when 
using them in terms of syntactic sugar. Constraints can either be expressible in 
DL or not. The majority - nearly 70% - of the overall constraints are expressible 
in DL. 


82.3 CWA and UNA Dependency 


— Dependent on the CWA: do further triples change the validation result? 

— Dependent on the UNA: Do validation results changes in case two resources 
are the same? 
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.4 Constraining Elements of Constraint Types 

Constraints of 64% of all constraint type can be expressed using logical 
constructs from description logics. 

For a constraint types, there can be multiple constraining elements 
The validation of each constraining element has to be implemented 
We use SPARQL as extension mechanism to express constraints of 3 con¬ 
straint types which cannot be expressed otherwise as they are too complex 
to represent them using a high-level constraint language 



Constraint Type 

DL 

Constraining Elements 

^Subsumption 


sub-class 

*Class Equivalence 

= 

equivalent class 

*Sub Properties 


sub-property 

^Property Domains 

3, c 

property domain 

^Property Ranges 

V 

property range 

^Inverse Object Properties 

inverse 

inverse property 

^Symmetric Object Properties 

symmetric 

symmetric property 

^Asymmetric Object Properties 

asymmetric 

asymmetric property 

^Reflexive Object Properties 

reflexive 

reflexive property 

*Irreflexive Object Properties 

reflexive, ^ 

irreflexive property 

Disjoint Properties 

- 

disjoint property 

Disjoint Classes 

n, ^ 

disjoint class 

Context-Sp. Property Groups 

n 

property group 

Context-Sp. Inclusive OR of P. 

u 

inclusive or 

Context-Sp. Inclusive OR of P. Groups 

u, n 

inclusive or 

Recursive Queries 

- 

recursive 

Individual Inequality 


different individuals 

^Equivalent Properties 

= 

equivalent properties 

Property Assertions 

= or ^ 


Data Property Facets 


SPARQL functions: 

REGEX, STRLEN 

XML Schema constraining facets: 

xsd:length, xsd:minLength, xsd:maxLength, xsd:pattern, 
xsd:enumeration, xsd:whiteSpace, xsd:maxlnclusive, 
xsd:maxExclusive,xsd:minExclusive, xsd:minlnclusive, 
xsd:totalDigits, xsd:tractionDigits 

Literal Pattern Matching 

- 

REGEX, xsd:pattern 

Negative Literal Pattern Matching 

- 

REGEX, xsd:pattern and — ■ 

^Object Property Paths 


property path 

^Intersection 

n 

intersection 

^Disjunction 

u 

disjunction 

^Negation 

- 

negation 

^Existential Quantification 

3 

existential quantification 

^Universal Quantification 

V 

universal quantification 

^Minimum Unqualified Cardinality 


minimum unqualified cardinality restriction 

^Minimum Qualified Cardinality 


minimum qualified cardinality restriction 

^Maximum Unqualified Cardinality 


maximum unqualified cardinality restriction 

^Maximum Qualified Cardinality 


maximum qualified cardinality restriction 

*Exact Unqualified Cardinality 

( n ) or 

= exact unqualified cardinality restriction 

*Exact Qualified Cardinality 

( n ) or 

= exact qualified cardinality restriction 

^Transitive Object Properties 

c 

transitive property 

Context-Sp. Exclusive OR of P. 

n, u 

exclusive or 

Context-Sp. Exclusive OR of P. Groups 

n, u 

exclusive or 

Allowed Values 

u 

allowed values 

Not Allowed Values 

LJ, ^ 

not allowed values 

Literal Ranges 

- 

xsd:minlnclusive, xsd:maxExclusive 
xsd:maxlnclusive, xsd:minExclusive 

Negative Literal Ranges 


—' and 

xsd:minlnclusive, xsd:maxExclusive 
xsd:maxlnclusive, xsd:minExclusive 

Required Properties 

3 

required property 




Constraint Type DL Constraining Elements 

Optional Properties 3, c optional property 

Repeatable Properties ^ repeatable property 

Negative Property Constraints 3 negative properties 

^Individual Equality = equal individuals 

^Functional Properties functional functional property 

*Inverse-Functional Properties inverse, functional inverse functional property 

*Value Restrictions 3 value restriction 

*Self Restrictions 3 self restriction 

Primary Key Properties inverse, functional primary key 


*Class-Specific Property Range c, 3, —■ 

*Class-Sp. Reflexive Object P. reflexive 

Membership in Controlled Vocabularies V, n, u 
IRI Pattern Matching 

Literal Value Comparison > or > or < 

^ or = or # 

Ordering 
Validation Levels 
String Operations 


Context-Specific Valid Classes 
Context-Specific Valid Properties 
Default Values 
Mathematical Operations 
Language Tag Matching 
Language Tag Cardinality 

Whitespace Handling 
HTML Handling 
Conditional Properties 
Recommended Properties 
Handle RDF Collections 

Value is Valid for Datatype 

Use Sub-Super Relations in Validation 

^Cardinality Shortcuts 


Aggregations 

*Class-Specific Irreflexive Object Properties reflexive, —■ 
Provenance 

Data Model Consistency 
Structure 

Labeling and Documentation 
Vocabulary 

HTTP URI Scheme Violation 


property range 
reflexive property 

membership in controlled vocabularies 
IRI pattern matching 
or >, <, =, ^ 

ordered properties, ordered values 
validation level 
SPARQL string functions: 

STRLEN, SUBSTR, UCASE, LCASE, 
STRSTARTS, STRENDS, CONTAINS, 
STRBEEORE, STRAFTER, ENCODE_FOR.URI, 
CONCAT, langMatches, REGEX, REPLACE 
context-specific valid classes 
context-specific valid properties 
default values 

addition, subtraction, multiplication, division 

language tag matching 

language tag minimum cardinality, 

language tag maximum cardinality, 

language tag exact cardinality 

no whitespaces 

no html 

conditional property 

recommended property 

actions on RDF collections: 

append list element 

value is valid for datatype 

non redundant properties 

optional & non-repeatable property, 

optional & repeatable property, 

mandatory & non-repeatable property, 

mandatory & repeatable property 

aggregations: 

count 

irreflexive property 
provenance information required 
<SPARQL query> 

<SPARQL query> 

<SPARQL query> 
vocabulary 

HTTP URI scheme violation 




83 Conclusion and Future Work 


There is no standard way to validate RDF data conforming to RDF constraints 
like XML Schemas serve to validate XML documents. Two working groups cur¬ 
rently try to achieve a solution for RDF validation - the W3C RDF Data Shapes 
working group and the DCMI RDF Application Profiles working group. We initi¬ 
ated a comprehensive database on RDF validation requirements: http://purl.org/net/rdf-validation. 
The intention of this database is to collaboratively work on case studies, use 
cases, requirements, and solutions on RDF validation. In this paper, we evalu¬ 
ated to which extend the five most promising constraint languages on being the 
standard (DSP, OWL2, ReSh, ShEx, and SPIN) fulfill each of the requirements 
to formulate RDF constraints. Each of these requirements corresponds to a type 
of constraint. The majority of the constraints can be expressed in DL, which 
serves as a logical underpinning of related requirements. We developed an on¬ 
tology to express any constraint generically, so that constrains expressed by a 
constraint language a can be transformed into constraints expressed by a con¬ 
straint language j3 without any information loss. By expressing any constraint 
generically, we can provide a validation of the generically expressed constraint. 

When specific constraints are then transformed into generic constraints, we can 
provide the validation of the semantically equivalent specific constraints (ex¬ 
pressed by multiple constraint languages) out-of-the-box without any additional 
effort and without any difference in validation results. As not every constrains 
can be represented in DL, we need to represent constraints expressible by DL as 
well as constraints not expressible by DL by means of this ontology. We shown in 
terms of an evaluation that any constraint can be expressed using the developed 
ontology. As part of future work, we will continuously add, modify, and maintain 
case studies, use cases, requirements, and solutions within the RDE validation 
requirements database. 
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